Unable to debug using jlink

[sAz-G]

I keep getting the following errors when I try the on chip debugging platform.

Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : auto-selecting first available session transport "jtag". To override use 'transport select '.
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : J-Link V11 compiled May 23 2023 14:44:38
Info : Hardware version: 11.00
Info : VTarget = 2.980 V
Info : clock speed 2000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020 (STMicroelectronics), part: 0x6413, ver: 0x0)
Info : TAP auto0.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto1.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto2.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto3.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto4.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto5.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto6.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto7.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto8.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto9.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto10.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto11.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto12.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto13.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto14.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto15.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto16.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto17.tap does not have valid IDCODE (idcode=0x0)
Info : TAP auto18.tap does not have valid IDCODE (idcode=0x0)
Warn : Unexpected idcode after end of chain: 83 0x00000000
Warn : Unexpected idcode after end of chain: 115 0x00000000
Warn : Unexpected idcode after end of chain: 147 0x00000000
Warn : Unexpected idcode after end of chain: 179 0x00000000
Warn : Unexpected idcode after end of chain: 211 0x00000000
Warn : Unexpected idcode after end of chain: 243 0x00000000
Warn : Unexpected idcode after end of chain: 275 0x00000000
Warn : Unexpected idcode after end of chain: 307 0x00000000
Warn : Unexpected idcode after end of chain: 339 0x00000000
Warn : Unexpected idcode after end of chain: 371 0x00000000
Warn : Unexpected idcode after end of chain: 403 0x00000000
Warn : Unexpected idcode after end of chain: 435 0x00000000
Warn : Unexpected idcode after end of chain: 467 0x00000000
Warn : Unexpected idcode after end of chain: 499 0x00000000
Warn : Unexpected idcode after end of chain: 531 0x00000000
Warn : Unexpected idcode after end of chain: 563 0x00000000
Warn : Unexpected idcode after end of chain: 595 0x00000000
Warn : Unexpected idcode after end of chain: 627 0x00000000
Error: double-check your JTAG setup (interface, speed, ...)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000000"
Error: auto0.tap: IR capture error; saw 0x0000 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Error: Invalid ACK (0) in DAP response

Occurs with:

arm-none-eabi-gdb
Ubuntu 22.04.2 LTS
segger jlink

I followed the instructions in the following link. I modified the configuration files and the launch.json file according to my jlink device. I also tried the on chip debugging for the nrf51, the same errors occur there too.

[ataffanel]

I think the problem is described in this line:

Info : auto-selecting first available session transport "jtag". To override use 'transport select '.

Both MCU in the Crazyflie uses the SWD transport and not jtag. In openOCD the command to switch transport is:

transport select swd

According to the cortex debug doc this can be done in launch.json with:

    "serverArgs": [
        "-c 'transport select swd'"
    ],

However I am have never tried that so it might need some tweaking.

What I would suggest instead is to switch server to either jlink or pyocd, in the launch.json:

    "servertype": "jlink",   // or "pyocd"

The jlink server requires downloading the Linux jlink driver and the pyocd server can be installed simply via the package manager or pip install pyocd. If you do not have the jlink tool install, test pyocd first (I have been thinking of switching to it for all our docs since it is much simpler to handle than OpenOCD ....).

[sAz-G]

Thanks for the hint. I solved the issue by adding the command transport select swd to the file pathToOpenocd/scripts/interface/jlink.cfg.

I also tried out your other suggestions, as explained below.

According to the cortex debug doc this can be done in launch.json with:

"serverArgs": [
    "-c 'transport select swd'"
],

I added this line to the launch.json file, and obtained the error Error: Can't change session's transport after the initial selection was made. Then I deleted the command from launch.json file, and add it to the jlink.cfg file manually as mentioned at the beginning of this answer.

What I would suggest instead is to switch server to either jlink or pyocd, in the launch.json:

"servertype": "jlink",   // or "pyocd"

First I tried using jlink. It worked fine, but I had to replace the line "device": "STM32F405", with "device": "STM32F405RG", . Otherwise the error Failed to get index for device name 'STM32F405'.GDBServer will be closed... occurs. The device name is taken from the segger website. The RG version is chosen according to the very last line in this documentation.

At the end I tried out also pyocd. The program could start, however it took it more time to stop at a code line, and it seems that it just stops somewhere in the program and not in the main function. Here is the output in the terminal

[2023-06-08T11:33:42.146Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
pyocd gdbserver --port 50000 --telnet-port 50001
0001591 W Generic 'cortex_m' target type is selected by default; is this intentional? You will be able to debug most devices, but not program  flash. To set the target type use the '--target' argument or 'target_override' option. Use 'pyocd list --targets' to see available targets types. [board]
0001594 I Target type is cortex_m [board]
0001845 I DP IDR = 0x2ba01477 (v1 rev2) [dap]
0001853 I AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2) [discovery]
0001861 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=020:ST part=411) [rom_table]
0001867 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0001872 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0001877 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0001884 I [3]<e0000000:ITM v7-M class=14 designer=43b:Arm part=001> [rom_table]
0001892 I [4]<e0040000:TPIU M4 class=9 designer=43b:Arm part=9a1 devtype=11 archid=0000 devid=ca1:0:0> [rom_table]
0001899 I [5]<e0041000:ETM M4 class=9 designer=43b:Arm part=925 devtype=13 archid=0000 devid=0:0:0> [rom_table]
0001904 I CPU core #0 is Cortex-M4 r0p1 [cortex_m]
0001906 I FPU present: FPv4-SP-D16-M [cortex_m]
0001908 I 4 hardware watchpoints [dwt]
0001912 I 6 hardware breakpoints, 4 literal comparators [fpb]
0001923 I Semihost server started on port 50001 (core 0) [server]
0002062 I GDB server started on port 50000 (core 0) [gdbserver]
0002519 I Client connected to port 50000! [gdbserver]
0002663 I Attempting to load RTOS plugins [gdbserver]
0002666 W FreeRTOS: pxReadyTasksLists size is unexpected, maybe an unsupported version of FreeRTOS. Try using the --elf option. [freertos]

I am new to the on chip debugging so I might be missing basic rules. Let me know if you want me to try other things

[ataffanel]

If I understand your message well, you got it to work with J-Link, in that case you should just use the J-Link server since it should be the best when using a J-Link debug probe anyway. So if it is the case your problem should be solved?

As for OpenOCD and pyocd, this is things that require investigation. For pyocd it is very strange that it stopped on the wrong line and it would indicate that the wrong file was used (mismatch between the flashed version and the file on the PC). I am especially interested by the last line in the log though: if we could get FreeRTOS support by default it would help a lot debugging (it allows to see the state of all the tasks when debugging, not only the one that has been broken).

[ataffanel]

Next step for this issue is to update the documentation for it to work with J-link and possibly trying to get PyOCD working by default.

[knmcguire]

Hi! I'm reopening one, as we still would need to add this to our documentation, as we treat issues as To Do's :)

[sAz-G]

If I understand your message well, you got it to work with J-Link, in that case you should just use the J-Link server since it should be the best when using a J-Link debug probe anyway. So if it is the case your problem should be solved?

As for OpenOCD and pyocd, this is things that require investigation. For pyocd it is very strange that it stopped on the wrong line and it would indicate that the wrong file was used (mismatch between the flashed version and the file on the PC). I am especially interested by the last line in the log though: if we could get FreeRTOS support by default it would help a lot debugging (it allows to see the state of all the tasks when debugging, not only the one that has been broken).

Yes. The problem is solved and I can debug using jlink debug module. For flashing I still use openocd, because the makefile provided in the crazyfie-firmware uses it. But for debugging I choose the jlink server