• State Not Answered
  • Replies 19 replies
  • Subscribers 87 subscribers
  • Views 4342 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 275268
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    Hello Mohamed,

    Could you specify which two lines you are referring to?
    Is it the NRF_BREAKPOINT_COND you are referring to?

    Could you also make sure to have DEBUG defined in your preprocessor defines, like shown in the included image?

    This will make the logger output a detailed error message whenever a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.

    Best regards,
    Karl

  • 0 in reply to Karl Ylvisaker

    Hi Karl,

    I am not sure what NRF_BREAKPOINT_COND is. But just before this problem started showing up I tried to set a data breakpoint breaking when a variable is set to a particular value. I thought it di not work because I could not see any breakpoint in the Breakpoints window in SES. Could it be that this data breakpoint is actually set but not showing up?

    Kind regards

    Mohamed Belaroussi

  • 0 in reply to Karl Ylvisaker

    Hi Karl,

    Thank you for trying to investigate this problem further.

    I will provide you with the requested information later on today.

    What is the correct way of setting a data breakpoint in Segger Embedded Studio?

    Note, I am using the version below.

    Learner said:

    SEGGER Embedded Studio for ARM

    Release 5.34a  Build 2021011401.44914

    Nordic Edition

    Windows x64

    Kind regards

    Mohamed

  • 0 in reply to Learner

    Hello again Mohamed,

    Learner said:
    I will provide you with the requested information later on today.

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

    Learner said:
    What is the correct way of setting a data breakpoint in Segger Embedded Studio?

    Click on the debug tab and select Breakpoints -> New Data Breakpoint option to setup a data breakpoint in Segger Embedded Studios. The new breakpoint will appear in the Breakpoints window. You can see the breakpoints windows if you click on Debug and select Breakpoints -> Breakpoints in the dropdown menu.
    It might also be helpful to have a look through Segger's own page regarding Data Breakpoints and how to use them.

    Best regards,
    Karl

  • 0 in reply to Karl Ylvisaker

    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 
  • 0 in reply to Learner

    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

  • 0 in reply to 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

Reply
  • 0 in reply to 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

Children
Related
Terms of service