Breakpoints problem

Follow

Paul Bayton

• February 18, 2016 10:28

Sometimes selected breakpoints are being ignored.

The setup is STM32 + JLINK + Crossworks 3.6.1
I am using both JLINK and JLINK-Ultra - both have this problem. DLL version is  V510d/JLinkARM.dll

It occurs is various STM32 devices.

When a breakpoint is set, the first few times it works fine, but then after a while is stops responding. If I do a 'break' and 'go', the breakpoint becomes active again.

Any suggestions ?

 

0

• 

  Dr Danish Ali

  • February 18, 2016 11:47

  Have you seen https://rowley.zendesk.com/entries/48410795-Breakpoints-Stop-Working ?

  It might be the same problem you're reporting, and there is a "nightly build" which seems to solve it for me.

   

  Hope this helps,

  Danish

  0

  Comment actions Permalink
• 

  Paul Bayton

  • February 18, 2016 12:13

  Thanks. I will try 3.6.2

  Actually Its been a problem for a little while now - since 3.5 I think. Just getting fed up and like to see it solved.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 04, 2016 11:52

  Is the application executing an __asm("wfi") instruction?

  0

  Comment actions Permalink
• 

  Paul Bayton

  • March 04, 2016 12:06

  No, just standard code.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 04, 2016 12:25

  Does it make a difference if you set "Use Builtin Flash Loader" to "No" on the j-link target properties.

  0

  Comment actions Permalink
• 

  Paul Bayton

  • March 04, 2016 12:46

  It still fails using the normal flash loader

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 04, 2016 13:52

  If you disconnect after each debug session does this change things?

  0

  Comment actions Permalink
• 

  Paul Bayton

  • March 08, 2016 12:19

  Not Really

  Looking at the jlink log file, the problem seems to be when a breakpoint is removed.

  normally when one is added the following command is sent: e.g.

  T35F8 2191:143 JLINK_WriteU32(0xE0002008, 0x8801DB5B) - FP_COMP[0]

  But that does not happen again once a breakpoint is removed.

  PS I cant find any reference to this address in the manuals.

  0

  Comment actions Permalink
• 

  Paul Bayton

  • March 08, 2016 12:37

  Hi

  Yes, I can confirm its the FlashPatch comparitor registers that are not being set after a breakpoint is removed.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 08, 2016 13:56

  I'd expect to see

  JLINK_WriteU32(0xE0002008, 0x8801DB5A)

  when the breakpoint is deleted i.e. the bottom bit is cleared.
  
  

  0

  Comment actions Permalink
• 

  Paul Bayton

  • March 08, 2016 15:16

  Yes, bit0 is cleared when removing or disabling, but no WriteU32 operations occur when setting them afterwards during program run.

  0

  Comment actions Permalink
• 

  Michael Johnson

  • March 08, 2016 16:34

  So the breakpoint is not cleared at the end of a debug session?

  0

  Comment actions Permalink
• 

  Paul Bayton

  • March 08, 2016 17:00

  Yes, they are cleared when stopping

  Its when breakpoints are added/removed during a debug session (in run mode) that there is a problem.

  After any breakpoint is removed, no more can be added.

  0

  Comment actions Permalink

Please sign in to leave a comment.