0

In my bare metal C application for a CM3, I have a startup script that runs a CRC on code and data sections in their target regions in memory. I noticed sometimes the check on code would fail, sometimes not, depending on if I had any breakpoints set. Well, I have determined from cause and effect that the extra breakpoints AFTER compilation ruined the CRCs on the code section, obviously because these breakpoints were added later by my IDE.

I wanted to check here whether the following proposal would be possible: In the CRC function, capture all extra breakpoints set at runtime in my code, and disable them so that the instructions would go back to as they were at compile, then run the CRC check function, then re-enable them at the end of that function.

Is there a way to do that? I think if not, then I'll just have to skip CRC checks during any debugging.

artless noise
  • 21,212
  • 6
  • 68
  • 105
us3rnotfound
  • 23
  • 3

1 Answers1

1

Is there a way to do that?

No - but it is not needed at all. They are there because you set too many breakpoints in your debugging software.

  1. Cortex-m3 can have from 2 (reduced implementation) to 6 hardware instruction comparators. If the address of the fetched instruction matches the programmed one the bkpt instruction is provided for the core.

  2. Some debug probe software (for example J-Link) provide software breakpoints. Software breakpoint is nothing else than the bkpt instruction programmed into the flash memory. It changes the original FLASH content. They are placed if you try to use more than the number of hardware breakpoints.

To prevent this behaviour simply disable software breakpoints in your debugging software or do not use more than you have hardware breakpoints (ie 2 or 6 depending on your hardware version [I know it is M3])

If you use J-Link debug probe you can use web interface to disable the hardware breakpoints (on this picture they are enabled):

enter image description here

0___________
  • 60,014
  • 4
  • 34
  • 74
  • Thanks. 1. So I didn’t realize a software breakpoint wrote to flash, what if I was remapped and running from a different memory than default (flash)? 2. I take it there is no method to query the current number of breakpoints via the arm? What about with GDB? 3. Also, would semihosting being enabled also contribute to the issue I am having? – us3rnotfound Feb 28 '23 at 01:33
  • @us3rnotfound semihosting does not use breakpoints. How to check: read manufacturer's documentation. – 0___________ Feb 28 '23 at 01:53
  • You could use a debugger script, to enable other breakpoints after a certain location (e.g. after CRC check finished). Jesus, I have a 15years back déjà vu on a ADI Blackfin .. same problem, (CRC + SoftBP) and same solution. :D – kesselhaus Feb 28 '23 at 06:19
  • Nice @kesselhaus, glad to hear it’s been done before! I’ll look into that. – us3rnotfound Feb 28 '23 at 11:46
  • On second thought the debugger script may not work for me, it seems to use the GDB commands advance or until, that inserts a breakpoint at the label so we’re back at the same issue. – us3rnotfound Feb 28 '23 at 23:30
  • @us3rnotfound reduce number of breakpoints - the best and the cleanest solution. – 0___________ Mar 01 '23 at 00:41