Debugging in VSCode gets stuck booting Zephyr OS

RE: Debugging in VSCode gets stuck booting Zephyr OS

Vidar Berg — Mon, 21 Nov 2022 11:15:52 GMT

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:

RE: Debugging in VSCode gets stuck booting Zephyr OS

deveryn — Sat, 19 Nov 2022 00:24:34 GMT

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!

RE: Debugging in VSCode gets stuck booting Zephyr OS

Vidar Berg — Fri, 18 Nov 2022 14:32:10 GMT

It's interesting that it works fine with the "hello world" sample. This indicates that the debugger and everything is configured correctly, at least.

Maybe you can try to build your application without the bootloader (CONFIG_BOOTLOADER_MCUBOOT=n) to see if it works better when you only have one FW image. This may help narrow down the problem.

The CPU registers can be viewed in the top left corner here:

[quote user="deveryn"]One thing I tried was disabling the "Enable debug options", creating a pristine build, and running the debugger. This seems to break inside "cpu_idle" when run and then a FIH_PANIC spot (see screenshot) when I hit pause, but continuing doesn't continue past when I hit continue (F5). I assume this is going down the wrong path but maybe it's helpful for debugging the problem?[/quote]

This shows that the program hangs inside MCUBoot because it did not find a bootable app. This can happen if only the mcuboot image is programmed to the device instead (i.e. if the zephyr.hex in build/mcuboot/zephyr/ was programmed instead of the merged.hex in build/zephyr)

RE: Debugging in VSCode gets stuck booting Zephyr OS

deveryn — Thu, 17 Nov 2022 17:49:29 GMT

One thing that's a clear difference between the hello_world example and my application is there's no "[Switching to Thread abcd]" after the [New Thread] lines in the debug console output of my application. It's like it gets stuck somewhere.

Here is the full debug console output for my app:

JLinkGDBServerCLexe: SEGGER J-Link GDB Server V7.82b Command Line Version
JLinkGDBServerCLexe: 
JLinkGDBServerCLexe: JLinkARM.dll V7.82b (DLL compiled Nov  9 2022 17:01:29)
JLinkGDBServerCLexe: 
JLinkGDBServerCLexe: -----GDB Server start settings-----
JLinkGDBServerCLexe: GDBInit file:                  none
JLinkGDBServerCLexe: GDB Server Listening port:     65228
JLinkGDBServerCLexe: SWO raw output listening port: 2332
JLinkGDBServerCLexe: Terminal I/O port:             2333
JLinkGDBServerCLexe: Accept remote connection:      yes
JLinkGDBServerCLexe: Generate logfile:              off
JLinkGDBServerCLexe: Verify download:               off
JLinkGDBServerCLexe: Init regs on start:            off
JLinkGDBServerCLexe: Silent mode:                   on
JLinkGDBServerCLexe: Single run mode:               on
JLinkGDBServerCLexe: Target connection timeout:     0 ms
JLinkGDBServerCLexe: ------J-Link related settings------
JLinkGDBServerCLexe: J-Link Host interface:         USB
JLinkGDBServerCLexe: J-Link script:                 none
JLinkGDBServerCLexe: J-Link settings file:          none
JLinkGDBServerCLexe: ------Target related settings------
JLinkGDBServerCLexe: Target device:                 nRF52832_xxAA
JLinkGDBServerCLexe: Target device parameters:      none
JLinkGDBServerCLexe: Target interface:              SWD
JLinkGDBServerCLexe: Target interface speed:        12000kHz
JLinkGDBServerCLexe: Target endian:                 little
JLinkGDBServerCLexe: 
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
arch_cpu_idle () at /opt/nordic/ncs/v2.1.2/zephyr/arch/arm/core/aarch32/cpu_idle.S:105
105		cpsie	i
[New Thread 536879720]
[New Thread 536878096]
[New Thread 536878280]
[New Thread 536879504]
[New Thread 536880088]
[New Thread 536878712]
[New Thread 536878496]
[New Thread 536879320]

And here is the full debug console output for hello_world:

JLinkGDBServerCLexe: SEGGER J-Link GDB Server V7.82b Command Line Version
JLinkGDBServerCLexe: 
JLinkGDBServerCLexe: JLinkARM.dll V7.82b (DLL compiled Nov  9 2022 17:01:29)
JLinkGDBServerCLexe: 
JLinkGDBServerCLexe: -----GDB Server start settings-----
JLinkGDBServerCLexe: GDBInit file:                  none
JLinkGDBServerCLexe: GDB Server Listening port:     65299
JLinkGDBServerCLexe: SWO raw output listening port: 2332
JLinkGDBServerCLexe: Terminal I/O port:             2333
JLinkGDBServerCLexe: Accept remote connection:      yes
JLinkGDBServerCLexe: Generate logfile:              off
JLinkGDBServerCLexe: Verify download:               off
JLinkGDBServerCLexe: Init regs on start:            off
JLinkGDBServerCLexe: Silent mode:                   on
JLinkGDBServerCLexe: Single run mode:               on
JLinkGDBServerCLexe: Target connection timeout:     0 ms
JLinkGDBServerCLexe: ------J-Link related settings------
JLinkGDBServerCLexe: J-Link Host interface:         USB
JLinkGDBServerCLexe: J-Link script:                 none
JLinkGDBServerCLexe: J-Link settings file:          none
JLinkGDBServerCLexe: ------Target related settings------
JLinkGDBServerCLexe: Target device:                 nRF52832_xxAA
JLinkGDBServerCLexe: Target device parameters:      none
JLinkGDBServerCLexe: Target interface:              SWD
JLinkGDBServerCLexe: Target interface speed:        12000kHz
JLinkGDBServerCLexe: Target endian:                 little
JLinkGDBServerCLexe: 
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
arch_cpu_idle () at /opt/nordic/ncs/v2.1.2/zephyr/arch/arm/core/aarch32/cpu_idle.S:105
105		cpsie	i
[New Thread 536871104]
[New Thread 536871280]
[Switching to Thread 536871280]

Thread 3 hit Breakpoint 1, main () at ../src/main.c:11
11		printk("Hello World! %s\n", CONFIG_BOARD);
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)

RE: Debugging in VSCode gets stuck booting Zephyr OS

deveryn — Thu, 17 Nov 2022 17:41:02 GMT

Thank you for the quick response. Pressing the Pause button doesn't seem to do anything. The Debug Console window doesn't seem to show any errors (see attached image).

Sorry for the basic question: what peripheral would I need to look at on the left to see the program counter?

One thing I tried was disabling the "Enable debug options", creating a pristine build, and running the debugger. This seems to break inside "cpu_idle" when run and then a FIH_PANIC spot (see screenshot) when I hit pause, but continuing doesn't continue past when I hit continue (F5). I assume this is going down the wrong path but maybe it's helpful for debugging the problem?

When I switch to the sample hello_world application on the same board the breakpoints work just fine.

RE: Debugging in VSCode gets stuck booting Zephyr OS

Vidar Berg — Thu, 17 Nov 2022 16:42:55 GMT

Hello,

I'm not sure if I have encountered this issue before. Are you able to see where it hangs if you press the "pause" button? If not, maybe you can check the CPU registers to see where the program counter is at.

Also, please check if there are any errors reported in the Debug console.

Thanks,

Vidar

RE: Debugging in VSCode gets stuck booting Zephyr OS

deveryn — Thu, 17 Nov 2022 15:15:56 GMT

Here is my project configuration if that's helpful:

# Bluetooth
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Stylus"
CONFIG_BT_DEVICE_APPEARANCE=0
CONFIG_BT_MAX_CONN=1
CONFIG_BT_LL_SOFTDEVICE=y

CONFIG_GPIO=y
CONFIG_DK_LIBRARY=y

# Logging
CONFIG_LOG=y
CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_DEFAULT_LEVEL=4

CONFIG_ASSERT=y

# DFU
CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_BT_L2CAP_TX_MTU=252
CONFIG_BT_BUF_ACL_RX_SIZE=256
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

# DEBUGGING
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y