This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5964: Unable to set breakpoint at __crt0_start() if breakpoints already defined

Part Number: MSP430FR5964

I've just starting tripping over a problem I've never seen before, and I'm struggling to understand what is causing it. 

Normally on reload or startup, the code automatically breakpoints at the main() entry point. The problem I am seeing is that if "some" breakpoints are already defined when I either reload or restart code, CCS (10.4) is reporting

No source available for "__crt0_start() at C:<>:{3} 0xfa00{4}"

in the source window, and 

MSP430: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x4a8e: Software breakpoints cannot be set on the given opcode.

in the Console.

The "some" above is important - leaving some breakpoints enabled causes no problems at all, whereas others will always trigger it. And just to complicate things, I've just reloaded the code, and a breakpoint that was previously fine is now triggering the problem as well (but see below!)

If I clear or disable all the existing breakpoints before restarting, everything works fine, and once running, breakpoints can be added, enabled and disabled at will.

Nothing has changed in CCS, or the build itself, other than the target executable being rebuilt and reloaded. I've tried restarting CCS, the FET, the PC, verified that HW breakpoints are set as the default (I recall reading somewhere that this was important), but nothing has made any difference (well, not quite true - restarting the FET seems to have reverted the breakpoint above back to working).

I normally leave most of my breakpoints in place when reloading/restarting code, and have never had an issues previously (other than the expected issues if the source has changed and CCS cannot resolve the breakpoint).

Any clues or ideas as to what I should be looking at?


BTW, the tool chain is GCC, running via CCS V10.4.0.

  • This is getting curlier.

    I just had a play setting an explicit breakpoint at main(), and not only did this work fine, but it also seems to have cleared any other problems (specifically when this breakpoint was subsequently removed), and its happily restarting the same executables with the same breakpoints in place.

    So for now, the problem has gone away. I'll leave it open for now in case someone can add any light to this.


  • Hi Andrew,

    This seems interesting. Anyway the problem has gone. I will leave this thread open for 2 weeks.

    Best regards,

    Cash Hao