• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 64 subscribers
  • Views 5209 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 276891
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unable to use debugger in VS Code using nRF Connect

AustinE

Similar, unresolved issue can be seen here.

I just got my official nRF52840DK and setup nRF Connect on my MacBook. I'm able to build the Blinky example and flash it to the board. However when launching debug mode there seems to be some kind of connection or handshake issue.

1) The break points in man.c are ever hit despite being on code that should execute (and an error appears when setting them. See below)

2) The light does not blink in debug mode

3)  When adding breakpoints to main.c I get a VS code error pop up saying "No line 49 in file "[PATH]/myfirstapp/src/main.c". (from break-insert "[PATH]/myfirstapp/src/main.c:49")

If I play around with pausing/resetting rapidly, I can get it to stop in cpu_idle.S(159) and step out to clock_control_nrf.c(513). However it wasn't clear what was breaking in debug mode.

Debug Console
Reading symbols from [PATH]/myfirstapp/build/zephyr/zephyr.hex...
(No debugging symbols found in [PATH]/myfirstapp/build/zephyr/zephyr.hex)
0x00001a2a in ?? ()
Program stopped, probably due to a reset and/or halt issued by debugger
add symbol table from file "[PATH]/myfirstapp/build/zephyr/zephyr.elf"
(y or n) [answered Y; input not from terminal]
Reading symbols from [PATH]/myfirstapp/build/zephyr/zephyr.elf...
2
Resetting target
Terminal Output
SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected
SEGGER J-Link GDB Server V7.54a Command Line Version

JLinkARM.dll V7.54a (DLL compiled Sep 7 2021 14:21:27)

Command line: -singlerun -nogui -if swd -port 50000 -swoport 50001 -telnetport 50002 -device nRF52840_xxAA -select usb=683165968 -rtos /Applications/SEGGER/JLink/GDBServer/RTOSPlugin_Zephyr.dylib
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 50000
SWO raw output listening port: 50001
Terminal I/O port: 50002
Accept remote connection: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: nRF52840_xxAA
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Feb 2 2021 16:47:20
Hardware: V1.00
S/N: 683165968
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 50000
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00001A2A (Data = 0xF3BFB662)
Read 2 bytes @ address 0x00001A2A (Data = 0xB662)
Loading RTOS plugin: //Applications/SEGGER/JLink/GDBServer/RTOSPlugin_Zephyr.dylib...
RTOS plugin (API v1.1) loaded successfully
RTOS_Init() core = 234881279
RTOS plugin: Loaded
RTOS_GetSymbols()
Received symbol: _kernel (0x20000E34)
Received symbol: _kernel_openocd_offsets (0x000059D8)
Received symbol: z_sys_post_kernel (0x20000E92)
All mandatory symbols successfully loaded.
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x00001A2A)
Received monitor command: reset
Resetting target
Downloading 16016 bytes @ address 0x00000000
Downloading 8244 bytes @ address 0x00003E90
Comparing flash [....................] Done.
Writing register (PC = 0x 1ac8)
Received monitor command: reset
Resetting target
Read 4 bytes @ address 0x00001AC8 (Data = 0xF3802000)
Read 2 bytes @ address 0x00001AC8 (Data = 0x2000)
Reading 64 bytes @ address 0x000003C0
Read 4 bytes @ address 0x0000045C (Data = 0x00005A68)
Read 2 bytes @ address 0x0000042A (Data = 0xF084)
Reading 64 bytes @ address 0x00000000
Read 4 bytes @ address 0x00000218 (Data = 0xF0FEFBB5)
Read 4 bytes @ address 0x0000033C (Data = 0xF109197D)
Read 2 bytes @ address 0x000003F4 (Data = 0xB538)
Read 2 bytes @ address 0x00000038 (Data = 0x1861)
Setting breakpoint @ address 0x00000038, Size = 2, BPHandle = 0x0001
Setting breakpoint @ address 0x000003F4, Size = 2, BPHandle = 0x0002
Setting breakpoint @ address 0x0000042A, Size = 2, BPHandle = 0x0003
Starting target CPU...
Parents
  • +1

    Hi,

    We have only been able to reproduce this issue when having checked the "Enable debug options" box when generating the Build Configuration together with samples that do not use threads. Can you see if this is the case in your setup as well? For instance, you should be able to debug Blinky if you do not select "Enable debug options", and all samples that use threads (like the Basic Thread Example and most complex samples) should work with "Enable debug options" enabled. 

    Checking "Enable debug options" adds several options to aid in debugging, including options that adds thread info structures to the firmware. This in turn is used by the Zephyr RTOS plugin for JlinkGDBserver. We suspect there is a bug here that causes this issue when no threads are used and will continue to look into that.

    In a nutshell: Leave "Enable debug options" unchecked for samples that does not use threads.

    Update: A workaround is to be to start debugging by Run -> Start Debugging (or pressing F5) instead of starting by clicking the "Debug Application" icon within the nRF Connect for VS Code plugin.

Reply
  • +1

    Hi,

    We have only been able to reproduce this issue when having checked the "Enable debug options" box when generating the Build Configuration together with samples that do not use threads. Can you see if this is the case in your setup as well? For instance, you should be able to debug Blinky if you do not select "Enable debug options", and all samples that use threads (like the Basic Thread Example and most complex samples) should work with "Enable debug options" enabled. 

    Checking "Enable debug options" adds several options to aid in debugging, including options that adds thread info structures to the firmware. This in turn is used by the Zephyr RTOS plugin for JlinkGDBserver. We suspect there is a bug here that causes this issue when no threads are used and will continue to look into that.

    In a nutshell: Leave "Enable debug options" unchecked for samples that does not use threads.

    Update: A workaround is to be to start debugging by Run -> Start Debugging (or pressing F5) instead of starting by clicking the "Debug Application" icon within the nRF Connect for VS Code plugin.

Children
No Data
Related