...Timeout... error when using JLinkClGDB.exe

[cHemingway]

Hi,

Thanks for this tool, I think it fills quite a unique space and I enjoy how standalone it is. I am trying to use it with a JLink using the JLink GDB Server instead of OpenOCD, but although it runs the server sucessfully and seems to connect to the port, I get a timeout error from metal.runner.

As far as I can see from the JLink log, the code has flashed correctly, and the breakpoint in metal_func_stub in metal_newlib_syscalls.c is hit. Grepping the sources, the string ...Timeout... is from metal.runner

My command line is
metal.runner --config-file="../test/metal_runner.cfg" --init-script="../test/test_script_gdb" --exe=bin/executable_unittest.elf

metal_runner.log

Starting run

=thread-group-added,id="i1"~"GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git\n"~"Copyright (C) 2017 Free Software Foundation, Inc.\n"~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"~"This GDB was configured as \"--host=x86_64-linux-gnu --target=arm-none-eabi\".\nType \"show configuration\" for configuration details."~"\nFor bug reporting instructions, please see:\n"~"<http://www.gnu.org/software/gdb/bugs/>.\n"~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n"~"For help, type \"help\".\n"~"Type \"apropos word\" to search for commands related to \"word\"...\n"~"Reading symbols from bin/executable_unittest.elf..."~"done.\n"GDB Version "GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128"
GDB Toolset ""
Config      "This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi""
0-target-select remote localhost:2331
=thread-group-started,id="i1",pid="42000"=thread-created,id="1",group-id="i1"~"main () at ../test/test_nand_flash.c:25\n"~"25\t    system_init();\n"*stopped,frame={addr="0x0000d70e",func="main",args=[],file="../test/test_nand_flash.c",fullname="/mnt/c/Users/chris/repos/apollo3_spi_nand/test/test_nand_flash.c",line="25"},thread-id="1",stopped-threads="all"0^connected1-interpreter-exec console "monitor reset"
@"Resetting target\r\n"Resetting target\r\n1^done2-interpreter-exec console "monitor halt"
2^done3-interpreter-exec console load
~"Loading section .text, size 0x3a94 lma 0xc000\n"3+download,{section=".text",section-size="14996",total-size="659923"}3+download,{section=".text",section-sent="14996",section-size="14996",total-sent="14996",total-size="659923"}~"Loading section .ARM.exidx, size 0x8 lma 0xfa94\n"3+download,{section=".ARM.exidx",section-size="8",total-size="659923"}~"Loading section .data, size 0xa8 lma 0xfa9c\n"3+download,{section=".data",section-size="168",total-size="659923"}~"Loading section .heap, size 0xc00 lma 0xfb44\n"3+download,{section=".heap",section-size="3072",total-size="659923"}~"Loading section .stack, size 0x800 lma 0xfb44\n"3+download,{section=".stack",section-size="2048",total-size="659923"}~"Start address 0xc000, load size 20292\n"~"Transfer rate: 9908 KB/sec, 4058 bytes/write.\n"3^done4-interpreter-exec console "monitor reset"
@"Resetting target\r\n"Resetting target\r\n4^done5-interpreter-exec console "monitor halt"
5^done6-interpreter-exec console "monitor halt"
6^done7-interpreter-exec console continue
~"Continuing.\n"7^running*running,thread-id="all"...Timeout...
Exited with code: -1

metal_runner_jlink.log

[Linked as very long]

metal_runner.cfg

dbg=arm-none-eabi-gdb
other="/mnt/c/Program Files (x86)/SEGGER/Jlink/JLinkGDBServerCL.exe" -If SWD -Speed 4000 -Device AMA3B1KK-KBR
remote=localhost:2331
timeout=10
log=metal_runner.log
debug=true
other-log="metal_runner_jlink.log"
lib="metal-newlib-syscalls metal-unit metal-exitcode"

test_script_gdb

monitor reset
monitor halt
load
monitor reset
monitor halt
continue

[klemens-morgenstern]

I think you need to add a custom init-script to get the device flashed. You can pass that to the runner with the option init-script, where you use the monitor command to upload your hex file.

Another thing you might wanna try is my WIP (!) of a python port, so you can skip the runner tool and just load the scripts from python. Usually that means you need to use arm-none-eabi-gdb-py if you use the ARM toolchain, and then you just need to add a gdbinit file that looks like this:

source metal-test/gdb-plugins/metal-exitcode.py
source metal-test/gdb-plugins/metal-newlib.py
source metal-test/gdb-plugins/metal-test.py

set print elements 0
set print repeats 0
target remote localhost:123456
monitor reset
load
continue

But keep in mind it's not done and I've only used it for exitcode & test so far.

[cHemingway]

Hi,

Thanks for the quick response! I have a script, but I forgot to attach it, now added. It is based on your openocd script

monitor reset
monitor halt
load
monitor reset
monitor halt
continue

[klemens-morgenstern]

Did that fix it?

[cHemingway]

Sorry no, I had that init-script originally, I just forgot to include it in the issue at the start.

Unfortunately, arm-none-eabi-gdb-py does not run for me, its having some problems finding libpython. I tried changing my init-script to match your suggestion, so :

monitor reset
load
continue

But this does not work either, getting the same timeout error.
Out of interest, what can cause ...Timeout..., no response from GDB? The tests not completing running?

[klemens-morgenstern]

It's probably that the target isn't running, try pass the --debug flag to the runner, that should tell you the interaction with gdb.

You just need to install python2.7 and gdb-py should work. I probably will give up the gdb runner in favor of the python version some time in the future.

[cHemingway]

Thanks again

I install python2.7, and libpython2.7, but no joy unfortunately. I suspect its an issue with using WSL

Checking the interaction with GDB, I get the same log file as I posted before, key final lines

6^done7-interpreter-exec console continue
~"Continuing.\n"7^running*running,thread-id="all"...Timeout...
Exited with code: -1

If I check the log for JLink.exe though (saved using the -log-other parameter), I get it repeatedly hitting a breakpoint at main (0x0000D70E). Using GDB's delete does not remove this breakpoint, neither does the JLink specific monitor clrbp

Starting target CPU...
...Breakpoint reached @ address 0x0000D70E
Reading all registers
Starting target CPU...
...Breakpoint reached @ address 0x0000D70E
Reading all registers
Starting target CPU...
...Breakpoint reached @ address 0x0000D70E
Reading all registers
Starting target CPU...
...Breakpoint reached @ address 0x0000D70E
Reading all registers
Starting target CPU...
...Breakpoint reached @ address 0x0000D70E
Reading all registers
Starting target CPU...
...Breakpoint reached @ address 0x0000D70E
Reading all registers
Starting target CPU...
[...repeats until end...]

[klemens-morgenstern]

Are you sure it actually hits any breakpoint? You should be able to manually check, by breaking for

• _exit
• metal_func_stub
• __metal_impl

when executing gdb manually.

It's weird that it doesn't work in the WSL. Works for me though I got a newer build.

[cHemingway]

Great news, I got the python version working! Thanks for your help! (I must not have installed Python properly), and it seems to hit the _exit breakpoint fine, and produces what I think is a test report.

I needed to modify your script to add an extra monitor reset, or else it would just freeze, so I have:

source test/metal_test/gdb-plugins/metal-exitcode.py
source test/metal_test/gdb-plugins/metal-newlib.py
source test/metal_test/gdb-plugins/metal-unit.py
set print elements 0
set print repeats 0
target remote localhost:2331
monitor reset
load
monitor reset
continue
quit

Running JLinkGDB and gdb-py

• "/mnt/c/Program Files (x86)/SEGGER/Jlink/JLinkGDBServerCL.exe" -If SWD -Speed 1000 -Device [snipped] -vd -logtofile -log "jlink_internal.log" -s
• arm-none-eabi-gdb-py -x ./test/metal_runner_gdb_py gcc/bin/executable_unittest.elf

This gives me the output finishing with:

Resetting target
Loading section .text, size 0x3ac4 lma 0xc000
Loading section .ARM.exidx, size 0x8 lma 0xfac4
Loading section .data, size 0xa8 lma 0xfacc
Loading section .heap, size 0xc00 lma 0xfb74
Loading section .stack, size 0x800 lma 0xfb74
Start address 0xc000, load size 20340
Transfer rate: 1324 KB/sec, 4068 bytes/write.
Resetting target
../test/test_main.c(31) assertion succeeded [expression]: 1
full test report: {executed: 1, warnings: 0, errors: 0}
{"cancelled": false, "tests": [{"critical": false, "file": "../test/test_main.c", "lvl": "assertion", "line": 31, "type": "plain", "message": "1", "condition": true}], "children": [], "summary": {"executed": 1, "errors": 0, "warnings": 0}}
Breakpoint 1, _exit (code=0) at ../test/test_main.c:39
39          while(1);

I presume this is JSON to feed into something else? I am happy to read this manually for now, especially as it has a summary line first.

If I change the gdb script for the C++ metal.runner to match the gdb python script, I still get the timeout error.

That is OK for me, I prefer this python option as then I don't need to compile anything host side. However the C++ bug still stands, so I think I should leave this issue open for now?

[klemens-morgenstern]

You should be able to redirect the json output by adding

set metal-test-json-file output.json

I am actively working on the python port for precisely that reason. The C++ version brings little advantages with a huge amount of work for me and a painful build for users. That's why I am working on the python version, plus it is way easier for you to extend. So I think once the python port is done I'll just merge that into master, but sure we can keep the issue open until then.

Also please feel free to ping me anytime, I'd be very interested if you run into some problems or need some extensions.

[cHemingway]

Great, thanks!
I definately prefer the python version, agree with you on that, easier to get going plus tons of nice libraries as you say.

Really appreciate the offer of help, I have not yet added any of my unit tests yet, so I will get going with those and get back to you if I run into any difficult issues or have any thoughts on an extension that might be useful for more than just me.