J-Link debugger failed to clear breakpoint: Target busy.

[hyperspacex2]

Describe the bug:
J-Link debugger failed to clear breakpoint: Target busy.

To Reproduce:

• Start debug session
• Set a breakpoint
• Clear the breakpoint
  • Debug Console shows: Failed to clear breakpoint: Target busy.
• Breakpoint is now always hit

If you set breakpoints before starting the debug session the chance of this happening is almost certain.

Expected behavior:
A breakpoint can be cleared at any time i.e. same behavior as in EWARM

Actual behavior:
Breakpoints are not shown in vs code anymore but debugger still hits them.

Environment:

• OS: Windows
• Embedded Workbench: Arm
• Embedded Workbench version: 9.4.1
• VSC Extension version: v1.30.4
• C-SPY version: 9.2.2.10770

Additional context:
C-Spy debug console output:

Using C-SPY version: 9.2.2.10770
Driver loaded: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm\bin\armjlink.dll
Expanded $TOOLKIT_DIR$\config\debugger\NXP\MIMXRT1062xxx6B.ddf -> C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm\config\debugger\NXP\MIMXRT1062xxx6B.ddf
Loading the J-Link Driver driver
Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm\config\debugger\NXP\iMXRT.dmac
Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm\config\debugger\NXP\iMXRT_Trace.dmac
Initializing flash loader manager using C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm\config\flashloader\NXP\FlashIMXRT1060_EVK_FlexSPI.board
Loading flash module: C:\GitProjects\myproject\iar\Debug\Exe\myproject.out
Loaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm/config/flashloader/NXP/FlashIMXRT1060_FlexSPI.mac
Logging to file: C:\GitProjects\myproject\iar\cspycomm.log
JLINK command: ProjectFile = C:\GitProjects\myproject\iar\settings\myproject_Debug.jlink, return = 0
Device "MIMXRT1062XXX6B" selected.
DLL version: V7.88b, compiled May 10 2023 14:13:45
Firmware: J-Link Pro V5-1 compiled Jul 18 2024 11:29:32
Serial number: xxxxxxxxx
Selecting SWD as current target interface.
JTAG speed is fixed to: 20000 kHz
InitTarget() start
InitTarget() end - Took 5.41ms
Found SW-DP with ID 0x0BD11477
DPIDR: 0x0BD11477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x04770041)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FD000
CPUID register: 0x411FC271. Implementer code: 0x41 (ARM)
Cache: L1 I/D-cache present
Found Cortex-M7 r1p1, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FD000
[0][0]: E00FE000 CID B105100D PID 000BB4C8 ROM Table
ROMTbl[1] @ E00FE000
[1][0]: E00FF000 CID B105100D PID 000BB4C7 ROM Table
ROMTbl[2] @ E00FF000
[2][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[2][1]: E0001000 CID B105E00D PID 000BB002 DWT
[2][2]: E0002000 CID B105E00D PID 000BB00E FPB-M7
[2][3]: E0000000 CID B105E00D PID 000BB001 ITM
[1][1]: E0041000 CID B105900D PID 001BB975 ETM-M7
[1][2]: E0042000 CID B105900D PID 004BB906 CTI
[0][1]: E0040000 CID B105900D PID 000BB9A9 TPIU-M7
[0][2]: E0043000 CID B105F00D PID 001BB101 TSG
I-Cache L1: 32 KB, 512 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
ResetTarget() start
ResetTarget() end - Took 151ms
AfterResetTarget() start
AfterResetTarget() end - Took 5.16ms
Hardware reset with strategy 2 was performed
Initial reset was performed
POWERTRACE: Emulator buffer size: 61760 bytes
FLASH MAC:Configure ITCM, DTCM and OCRAM
Loaded debugee: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm/config/flashloader/NXP/FlashIMXRT1060_FlexSPI.out
Target reset
Unloaded macro file: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm/config/flashloader/NXP/FlashIMXRT1060_FlexSPI.mac
Downloaded C:\GitProjects\myproject\iar\Debug\Exe\myproject.out to flash memory.
554080 bytes downloaded into FLASH (30.26 Kbytes/sec)
Flash loading completed successfully.
Loaded debugee: C:\GitProjects\myproject\iar\Debug\Exe\myproject.out
Loaded custom formats file: C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm/config/custom_formats.dat
Loaded custom formats file: C:\GitProjects\myproject\iar/custom_formats.dat
ResetTarget() start
ResetTarget() end - Took 139ms
AfterResetTarget() start
AfterResetTarget() end - Took 3.71ms
Hardware reset with strategy 2 was performed
Download completed.
ResetTarget() start
ResetTarget() end - Took 139ms
AfterResetTarget() start
AfterResetTarget() end - Took 3.15ms
Software reset was performed
Target reset
Using 'auto' breakpoint type.
Session started
Update all software breakpoints was performed
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:175.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)
Failed to clear breakpoint: Target busy.
Breakpoint hit: Code @ myfile.cpp:175.4, type: default (hardware)
Breakpoint hit: Code @ myfile.cpp:186.4, type: default (hardware)

launch.json (configurations, driverOptions):

"driverOptions": [
"--crun=disabled",
"--endian=little",
"--cpu=Cortex-M7",
"--fpu=VFPv5_D16",
"-p",
"$TOOLKIT_DIR$\config\debugger\NXP\MIMXRT1062xxx6B.ddf",
"--semihosting",
"--device=MIMXRT1062xxx6B",
"--drv_communication_log=C:\GitProjects\myproject\iar\cspycomm.log",
"--drv_communication=TCPIP:175104252",
"--drv_interface_speed=20000",
"--drv_default_breakpoint=1",
"--drv_restore_breakpoints=_call_main",
"--jlink_reset_strategy=0,2",
"--drv_interface=SWD",
"--drv_catch_exceptions=0x000",
"--drv_swo_clock_setup=117333000,0,40000000",
"--jlink_device_name=MIMXRT1062xxx6B",
],
No matter what option is selected for --drv_default_breakpoint the problem consists.

A documented command to manually clear a breakpoint via debug console would also be quite helpful for now.

[jlonnberg]

@hyperspacex2
Can you attach the cspycomm.log file, please?

[hyperspacex2]

@hyperspacex2 Can you attach the cspycomm.log file, please?

I would gladly do so only the cspy logging seems to a broken feature, unless I have some misconfiguration.

In the launch.json that I'm using under "driverOptions" an absolut path for the log file is used. It is set to "--drv_communication_log=C:\GitProjects\myproject\iar\cspycomm.log". This is the exact same path where the log appears if I start debugging from within EWARM. Changing the filename to *_vscode.log (to rule out interference by EWARM) has no effect on this.

In the vs code debug console, however, the ouput suggests the log file is correctly configured:
Logging to file: C:\GitProjects\myproject\iar\cspycomm.log

So the only thing I can provide is the debug output from the original comment unless you are interested in the cspy log from EWARM.

[jlonnberg]

I see. Does the EW generate the log file when you run the same project or does it also fail?

[hyperspacex2]

I see. Does the EW generate the log file when you run the same project or does it also fail?

It does generate a log in EW with the same project.

[jlonnberg]

@hyperspacex2 Hmm, that was not good. Do you by any change have access to another version of the embedded workbench that you can test with?

[jlonnberg]

@hyperspacex2 I've done some additional testing, e.g., trying to generate a cspycomm.log file using the same EW version as you and I had no problems what-so-ever in doing so so I'm still struggling to reproduce the problem. I've spoken to a colleague about the problem as such, and it may be related to vscode trying to access the the low-level parts in the driver while it's communicating with the device.

It would be great if you could try the following:

1. Delete the launch.json and start from scratch so that we know that it's not the launch.json triggering the problem.
2. Try re-running and see if the problem still occurs
3. It seems like you are debugging using TCPIP, can you try debugging locally just to check if that might be the problem.

[hyperspacex2]

@hyperspacex2 I've done some additional testing, e.g., trying to generate a cspycomm.log file using the same EW version as you and I had no problems what-so-ever in doing so so I'm still struggling to reproduce the problem. I've spoken to a colleague about the problem as such, and it may be related to vscode trying to access the the low-level parts in the driver while it's communicating with the device.

It would be great if you could try the following:

1. Delete the launch.json and start from scratch so that we know that it's not the launch.json triggering the problem.
2. Try re-running and see if the problem still occurs
3. It seems like you are debugging using TCPIP, can you try debugging locally just to check if that might be the problem.

Thank you for taking a closer look. I did have a misconfiguration, a typo in the path. Sorry for wasting your time.
I have attached the log where a breakpoint was hit and could not be removed again: cspycomm.log

[jlonnberg]

@hyperspacex2 It seems that you've stumbled upon a problem with how vscode handles breakpoints. VS Code semm to unconditionally remove the bp marker from the UI regardless if the bp was removed or not.
I've added microsoft/vscode#233839 for future reference. We'll add some printing for now to inform the user that we've failed to remove a bp.

[hyperspacex2]

@hyperspacex2 It seems that you've stumbled upon a problem with how vscode handles breakpoints. VS Code semm to unconditionally remove the bp marker from the UI regardless if the bp was removed or not. I've added microsoft/vscode#233839 for future reference. We'll add some printing for now to inform the user that we've failed to remove a bp.

Many thanks. Is there any way to clear the breakpoint manually with c-spy? Maybe directly with a command in the debug console. Otherwise could it be possible and useful to print the "<BP_Handle>" so we could use jlink commander to clear it (see ClearBP)? I have no idea if possible or if that even makes sense.