Debugging in VSCode gets stuck booting Zephyr OS

I've been trying to get breakpoints working on a new nRF Connect project but have been running into an issue: when I hit "Debug" in the nRF Connect plugin in VSCode, the app compiles, loads, and logs everything from my application, but seems to ignore the breakpoints. Then, it seems to reboot, because it says it's loading Zephyr again, but this time it never succeeds. The call stack on the left has values but then quickly becomes empty.

I am using a nRF52DK (nRF52832) and am also experiencing the same issue with a BMD-300 Dev Kit.

Here is the log:


*** Booting Zephyr OS build v3.1.99-ncs1-1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
�*** Booting Zephyr OS build v3.1.99-ncs1-1 ***
[00:00:00.004,699] <inf> [Logs from myapp showing that the main() function finished successfully.]
*** Booting Zephyr OS build v3.1.99-ncs1-1 ***

The device seems to hang at this point and isn't advertising via BLE. When I load the same app without the debugger, it advertises and works perfectly.

A few things I have already tried:
1. I made sure the "Enable debug options" is checked for my build configuration and did a pristine build
2. I restarted VSCode
3. I unplugged and plugged in the device

I've attached an image of the setup if that's helpful.

Any help you could provide would be greatly appreciated. Thank you.

  • Thank you for getting back to me. Setting CONFIG_BOOTLOADER_MCUBOOT to "n" did seem to fix the issue - the breakpoints are hit and I can walk through the app.

    While debugging this, I accidentally stopped a flash halfway through, which made the J-Link debugger not respond when programming with VSCode. I used the nRF Connect desktop app to program the merged.hex file. Then, all of a sudden, the debugging started working with and without the CONFIG_BOOTLOADER_MCUBOOT=n value!

    Do you know why this would happen so I can avoid running into the issue in the future?

    Either way, thank you for your help!

  • I'm glad to hear that it works now, but I'm afraid I don't have an explanation as to why this issue occured in the first place. I tried to reproduce the problem here by debugging a project which included MCUBoot, but no luck. 

    If you happen to encounter this again, please try to use Segger Ozone to see if it gives you the same problem. I'm trying to understand if the issue may be related to the debugger configuration or not.

    The "Debug with Ozone" button should appear here if you have Ozone installed:

Related