Can't Debug with image including MCUBoot Bootloader

[Pamela Keiles]

Hello,

I am trying to work with the MCUBoot bootloader in my project. I was able to configure and build my project and it appears to run properly when I flash it to the chip directly. However when I try to debug it I get the following error:

Run to 'main' timed out. Trying to pause program

The full debug console output was as follows:

Launching gdb-server: "C:\\Program Files (x86)\\SEGGER\\JLink\\JLinkGDBServerCL.exe" -singlerun -nogui -if swd -port 50000 -swoport 50001 -telnetport 50002 -device nRF52832_xxAA -select usb=682211915 -rtos "C:\\Program Files (x86)\\SEGGER\\JLink\\GDBServer\\RTOSPlugin_Zephyr.dll"

Please check TERMINAL tab (gdb-server) for output from C:\Program Files (x86)\SEGGER\JLink\JLinkGDBServerCL.exe

Finished reading symbols from objdump: Time: 63 ms

Finished reading symbols from nm: Time: 60 ms

Reading symbols from c:\Soberlink\soberlink_sfw\trunk_NordicBLE\SL_Connect_ST\build_connect\zephyr\merged.hex...

(No debugging symbols found in c:\Soberlink\soberlink_sfw\trunk_NordicBLE\SL_Connect_ST\build_connect\zephyr\merged.hex)

WARNING: Cortex-Debug will deprecate use of GDB version 8 after July 2022. Please upgrade to version 9+

0x0002e6a2 in ?? ()

Program stopped, probably due to a reset and/or halt issued by debugger

add symbol table from file "c:/Soberlink/soberlink_sfw/trunk_NordicBLE/SL_Connect_ST/build_connect/zephyr/zephyr.elf"

(y or n) [answered Y; input not from terminal]

Reading symbols from c:/Soberlink/soberlink_sfw/trunk_NordicBLE/SL_Connect_ST/build_connect/zephyr/zephyr.elf...

add symbol table from file "c:/Soberlink/soberlink_sfw/trunk_NordicBLE/SL_Connect_ST/build_connect/mcuboot/zephyr/zephyr.elf"

(y or n) [answered Y; input not from terminal]

Reading symbols from c:/Soberlink/soberlink_sfw/trunk_NordicBLE/SL_Connect_ST/build_connect/mcuboot/zephyr/zephyr.elf...

2 Resetting target

[New Thread 536878408]

[New Thread 536877856]

[Switching to Thread 536878408]

Reading symbols from c:\nordicsemi\v1.9.1\toolchain\opt\bin\arm-none-eabi-objdump.exe --syms -C -h -w c:\Soberlink\soberlink_sfw\trunk_NordicBLE\SL_Connect_ST\build_connect\zephyr\merged.hex

Reading symbols from c:/nordicsemi\v1.9.1\toolchain\opt\bin\arm-none-eabi-nm.exe --defined-only -S -l -C -p c:\Soberlink\soberlink_sfw\trunk_NordicBLE\SL_Connect_ST\build_connect\zephyr\merged.hex

Launching GDB: "c:\\nordicsemi\\v1.9.1\\toolchain\\opt\\bin\\arm-none-eabi-gdb.exe" -q --interpreter=mi2 "c:\\Soberlink\\soberlink_sfw\\trunk_NordicBLE\\SL_Connect_ST\\build_connect\\zephyr\\merged.hex"

Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems

Run to 'main' timed out. Trying to pause program

I even tried to use a standard example (BLE peripheral) and got the same results. Any suggestions what could causing the bootloader to hang only while debugging?

Thanks and regards,

Pam

[Pamela Keiles]

Hi Einar,

I wasn't able to get the "overlay-bt.conf" version of the project to build because it is too large for the NRF52832. However I did get the "overlay-bt-tiny.conf" and the "overlay-serial.conf" versions to build and run on the dev board. 

After referencing this sample project I tweaked my own project and was able to get it to download and successfully run as well with the debugger. Although it doesn't work consistently, sometimes there are issues where it gets "stuck" and never makes it out of the bootloader after the download. I'm still trying to identify the exact problem, but maybe it's related to the state of the chip along with the external hardware on the board?

I will try to see if I can get somewhere on the DFU design in my project. Is there any documentation on the SMP protocol if I end up using that versus something custom? The update image is being transferred via the UART from a different processor in our device so the application on the Nordic chip just has to write the new image to flash and initiate the switch/update via the bootloader.

Thanks,

Pam

[Einar Thorsrud]

Hi Pam,

Pamela Keiles said:

After referencing this sample project I tweaked my own project and was able to get it to download and successfully run as well with the debugger.

That is good to hear.

Pamela Keiles said:

Although it doesn't work consistently, sometimes there are issues where it gets "stuck" and never makes it out of the bootloader after the download. I'm still trying to identify the exact problem, but maybe it's related to the state of the chip along with the external hardware on the board?

That could be. It id difficult to say without knowing more. It could make sense to debug to bootloader to see what state it is in when it is seemingly stuck.

Pamela Keiles said:

Is there any documentation on the SMP protocol if I end up using that versus something custom?

The Simple Management Protocol (SMP) protocol comes from the mcumgr project. The documentation is unfortunately sparse, though. Or as they put it in the mcumgr documentation: "Information and documentation for mcumgr is stored within the source". There is a small chapter on the protocol, though.

Einar

[Pamela Keiles]

Hi Einar,

I am still having a problem with debugging when the "mcuboot" is included in my build. I don't experience these issues when the bootloader is not included. Here is some of the output from the debug console window when the debugger stalls (after the code is downloaded).

Reading symbols from c:/Soberlink/soberlink_sfw/trunk_NordicBLE/SL_Connect_ST/build_connect/mcuboot/zephyr/zephyr.elf...
2
Resetting target
[New Thread 536878448]
[New Thread 536877896]
[Switching to Thread 536878448]
Run to 'main' timed out. Trying to pause program
GDB never responded to an interrupt request. Trying to end session anyways

Could there be a RAM issue perhaps causing it to have difficulty switching threads? I'm struggling with how to debug this, I don't see an easy way to work with any type of debugging in the bootloader.

Any help would be great. I can get it to work when I select "Recover Board" via the connected JTAG device just before the download. But I have to do this every time to get it to work.

Thanks for your help and best regards,

Pam

[Pamela Keiles]

Hi Einar,

It seems like a Visual Studio or Zephyr bug of some sort. See the case below, this is the exact issue I have run across. I'll work around it for now as suggested by using a build without the debug option selected or incorporate multiple threads.

https://devzone.nordicsemi.com/f/nordic-q-a/79881/unable-to-use-debugger-in-vs-code-using-nrf-connect/330690#330690

Thanks and regards,

Pam

[Einar Thorsrud]

Hi Pam,

Thanks for updating me on your findings. It is a bit strange that I was not able to reproduce it though, and this issue should have been fixed. Can you let me know which VS Code version and which version of the nRF Connect for VS Code plugin you have?

Einar

[Pamela Keiles]

Hi Einar,

I am using:   Visual Studio Version 1.67.1  and nRF Connect Version 2022.4.219

Also, I see this error message every time I run the debugger:

WARNING: Cortex-Debug will deprecate use of GDB version 8 after July 2022. Please upgrade to version 9+

Any idea if this is a concern or how to update this "Cortex-Debug" software?

Thanks and regards,

Pam

[Einar Thorsrud]

Hi Pam,

Thanks for the version info - that was the latest until today and should been good. I will forward it to the team working on the plugin, though I cannot promise any fast progress (at least not while not being able to reproduce).

Regarding the warning that is just an informational notice about future deprecation, and should be addressed in due time. And I recommend you use whatever we provide with the nRF Connect for Desktop Toolchain manager, as that is tested. You can see this thread for a bit more info.