Segger EMBEDDED STUDIO debugger breaks at random lines

[Learner]

Hello

I am running this version of SES

SEGGER Embedded Studio for ARM

Release 5.34a  Build 2021011401.44914

Nordic Edition

Windows x64

When I run my program in Segger it keeps stopping at these two particular lines. I do not understand why it is breaking because there are no breakpoints set. I deleted all of them.

It seems as if there are two 'hidden' breakpoints at these two lines. The Breakpoints window shows none.

Can someone please help?

Kind regards

Mohamed

[Learner]

Good Morning Karl,

Karl Ylvisaker said:

Did you get a chance to look at this further? Or is this perhaps not an issue anymore?

Not an issue anymore.

Karl Ylvisaker said:

Click on the debug tab and select Breakpoints -> New Data Breakpoint option to setup a data breakpoint in Segger Embedded Studios.

I did setup a data breakpoint as you described but the program never stops and I know full well the condition is occurring. The breakpoint I set is to break when when the expression  cnt==1 is true. I know the counter cnt is incremented because when I set a normal breakpoint on the line where it gets incremented the program does break. Note, cnt is a volatile int16_t but I don't think this explains the behaviour I am seeing.

Kind regards

Mohamed 

[Karl Ylvisaker]

Hello again, Mohamed

Thank you for your patience with this. 

Learner said:

Not an issue anymore.

I am glad to hear that this is no longer an issue for your development.

Learner said:

I did setup a data breakpoint as you described but the program never stops and I know full well the condition is occurring. The breakpoint I set is to break when when the expression  cnt==1 is true. I know the counter cnt is incremented because when I set a normal breakpoint on the line where it gets incremented the program does break. Note, cnt is a volatile int16_t but I don't think this explains the behaviour I am seeing.

Hm, this looks correct to me. I just tested this here on my end, and I am seeing the same behavior you describe - strange!
I have created an internal ticket for this so that our SES NE developers may examine this more closely.
Thank you for bringing this to our attention! :) 

Best regards,
Karl

[Karl Ylvisaker]

Hello again, Mohamed

I just heard back from our SES NE developers and they are already aware of the issue and have raised an issue with Segger directly. In the meantime, they had this to say about the issue:

Data breakpoints have a certain latency so the program will stop a few instructions after the actual variable is updated. To verify add some dummy linear code lines (for instance a few volatile vars which are incremented) after the watched counter is changed. To get a precise analysis of a stray variable write from a crazy pointer you have to use instruction trace and look a couple of instructions back in the trace from where the program stops. This latency does not apply to program break points as they operate on the program counter.

So this should function as a workaround while we wait for it to be fixed. I hope it helps! :)

Best regards,
Karl

[Learner]

Good Morning Karl,

Thank you for your help.

Karl Ylvisaker said:

Data breakpoints have a certain latency so the program will stop a few instructions after the actual variable is updated.

I think I found that my program never stopped and I thought you also confirmed this in your previous message. So, putting extra dummy instructions will not help. 

Did you see you program stopping few instructions after the actual variable was updated?

Kind regards

Mohamed 

[Karl Ylvisaker]

Hello again, Mohamed

Thank you for your patience with this.

Learner said:

Did you see you program stopping few instructions after the actual variable was updated?

Yes, I see the program stopping a few instructions after the data breakpoint condition was met. You will need to make sure that the variable is a global one, so they have a fixed address instead of being on the stack.

I have included a simple demonstration of this made for the nRF52840 DK with the nRF Connect v1.6.1 toolchain. Place it in \v1.6.1\zephyr\samples\basic\ and see if it works.
Please run this and see if you see the breakpoint triggering when the tester_variable is equal to 5.

Best regards,
Karl

5126.blinky_databreakpoint.zip