Sunday, December 17th 2017, 2:35pm UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Date of registration: Mar 11th 2012

Posts: 24

1

Tuesday, February 18th 2014, 1:35pm

Connecting to target by any jlink utility while debugging disables breakpoints

When target running under GDB Server session (with breakpoints set) I connect to target by any JLink utility (for example, just launch JLink Commander). This causes breakpoints not hit anymore until I do something with debugger (for example, just pause and continue running).

Quoted


DLL version V4.80g, compiled Feb 13 2014 20:50:02
Firmware: J-Link ARM-Pro V3.x compiled Sep 19 2013 20:11:52
Hardware: V3.00

STM3220G-EVAL Rev.B board (ARM Cortex-M3)
Windows 7 Pro SP1 64-bit

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,514

2

Thursday, February 20th 2014, 8:43am

Hi,

Hard to believe...
Usually, for most Cortex-M targets having multiple connections to the same target opened at the same time should work correctly (with some limitations).
We will check if we can reproduce this in any way.

For reproduction:
Could you please provide the steps we need to do?

- Starting GDBServer session
- Set breakpoints in GDBServer session at ... ... ...
- Start CPU and let it hit a breakpoint
- Start J-Link Commander in parallel
- Start CPU in GDB session again => Next breakpoint is not hit (?)

Correct so far?


Best regards
Alex

Date of registration: Mar 11th 2012

Posts: 24

3

Thursday, February 20th 2014, 9:54am

Correct steps to reproduce:
- start GDBServer session
- set breakpoints in GDBServer session (they must be triggered by timer or external events you may generate)
- start CPU
- let it hit a breakpoint (CPU paused)
- continue CPU
- start J-Link Commander in parallel
- let breakpoint hit again (here is the problem - it will not hit)
- pause and continue CPU
- let breakpoint hit again (this time it succeeds)

Date of registration: Mar 11th 2012

Posts: 24

4

Monday, March 17th 2014, 9:11am

Upgraded to V4.82. The issue is still actual.

Date of registration: Mar 11th 2012

Posts: 24

5

Wednesday, May 6th 2015, 8:42am

Upgraded to 4.98e. The issue is still actual.
Are you going to fix it ?

Tj256

Beginner

Date of registration: Oct 21st 2014

Posts: 25

6

Wednesday, May 6th 2015, 5:44pm

Similar issue with PIC32

This may be the same or related bug: On the Pic32 I have to do a pause and continue to get breakpoints to work at all. I guess I just got used to it since for quite a long time I've been just habitually doing this every debug session. I have many other showstoppers that prevent me from debugging (like viewing unmapped memory crashing my program) that I ignore issues like this since there's the stop/continue workaround.

This post has been edited 1 times, last edit by "Tj256" (May 6th 2015, 5:51pm)


Date of registration: Mar 11th 2012

Posts: 24

7

Wednesday, May 6th 2015, 6:27pm

I used same workaround until there was a need to perform connection by jlink software very often. It become extremely annoying.
Right now I'm implementing dirty workaround with gdb python scripting and software breakpoint in order to automate "stop/continue" action. (It still be possible to miss breakpoints in very rare cases, but at least debugging process becomes smoother...)