J-Link Debugging does not stop at breakpoints

[grindstaffp]

I have made a few system changes since I last attempted a debug on any project but noticed today that while breakpoints were being set, the debug session would not stop at any breakpoint, regardless of where it was set. I am using J-Link to debug and this configuration had worked fine in the past. Please see attached log for more context as to what may be going on.

I am able to program devices no problem with the J-Link and the below is the test output from VisualGDB Project Properties -> Debug Settings -> Test

C:\Program Files\SEGGER\JLink\JLinkGDBServerCL.exe -select USB -device nRF52840_xxAA -speed auto -if SWD -port 54485
SEGGER J-Link GDB Server V7.58d Command Line Version

JLinkARM.dll V7.58d (DLL compiled Dec 2 2021 15:27:01)

Command line: -select USB -device nRF52840_xxAA -speed auto -if SWD -port 54485
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 54485
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
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: auto
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V11 compiled Dec 1 2021 16:59:54
Hardware: V11.00
S/N: **********
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.18 V
Listening on TCP/IP port 54485
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
GDB closed TCP/IP connection (Socket 932)
Restoring target state and closing J-Link connection...
Shutting down...

Environment:

• Visual Studio 2022 CE
• VisualGDB 5.6R2
• J-Link 7.58d

• This topic was modified 2 years, 11 months ago by grindstaffp.

Attachments:

You must be logged in to view attached files.

[grindstaffp]

After doing a little more testing, debugging works fine in a different project so it seems to be an issue with the project, not necessarily VisualGDB or J-Link.

[support]

Hi,

Yes, we can confirm that according to the log, the breakpoint appears to be set correctly (the reply to -break-insert contains an actual resolved address). Most likely, the project crashes somewhere else and the breakpoints simply don’t get a chance to trigger.

[grindstaffp]

I had considered that and placed a breakpoint within the main function prior to any other function calls and was met with the same result, the breakpoint was never reached. The firmware meanwhile was running on the device and live variables were refreshing while running.

[support]

It’s hard to say what could be causing this behavior. As far as VisualGDB is concerned, the target confirms the setting of a breakpoint, and never reports that it has triggered. If the firmware is running successfully, it could have disabled some debugging functionality, or could have overwritten the memory. The best way to troubleshoot this type of issues is to compare the project against a reference one where the breakpoints do work, and try eliminating the differences between them one by one.

[grindstaffp]

Thanks for the suggestions. I will do more testing and hopefully find a solution. I do not know what could have changed since the last time I successfully ran a debug on this project but I’ve obviously made something unhappy.

[Author]

Posts