I have been seeing flaky behavior from the software breakpoints for a while, but have still had good luck with HW breakpoints, except there aren't enough of those. I guessed that it had something to do with the debugger loosing track of where lines were, when I added a line , or commented a block out, until today....
Today, I noticed that the software BP would stop working every time I reloaded to change only the argument of one assignment line, it was only a one bit change, so it should not affect the instruction ordering. Here is a screen shot, with an 1 error shown when it works only on the HW break point, but not the 3 obviously marked, and enabled, SW breakpoints...it just runs until it gets back to line 205, where the HW breakpoint is. This is how it looks and works just after a Debug/Reload(F11)
Now if I double click each of the SW breakpoint "blue dots" on lines 210,222,234, then everything works , and it stops properly on each breakpoint, but now I get four red errors listed in the console, perhaps one for each break-point? Screenshot below:
And that works until, I Debug/Reload via F11 again, and then it goes back to the behavior in the first screen shot.
Supporting Details:
- CCS v6 Version: 6.0.0.00190
- TMS28069
- Code is in flash but moved to 28069 RAM on boot, thus all breakpoints are in RAM
- Spectrum Digital XDS560V2 Traveler Emulator
- Another problem that I've had since going version 6 is the the Auto Complete, via Ctrl-Space, doesn't seem to work all the time, especially for enumerated types, and register structs. I had to manually look up the exact spelling of SpiaRegs.SPIFFRX.bit.RXFIFORESET yesterday, which was excessively tedious. This may not be related.