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.
CCS v6 Breakpoints not reloading after each "Debug( F11)"
Why do my software breakpoints keep disappearing?
I have a breakpoint set in code which is loaded into Flash and then runs from RAM. The breakpoint is set in RAM region where the code runs. Sometimes this breakpoint halts the code, sometimes it does not.
I noticed that when I issue a new run (reset -> run) that's when the breakpoint seems to disappear.
Lori HeustessC2000 Software Engineering
In C2000 applications, software breakpoints set in code regions that are loaded to Flash but run from RAM and enabled prior to loading code, may not work as expected. The breakpoints will appear be set correctly in the RAM address but program will not halt when the code is run the first time after a load/reload. If the breakpoint is simply disabled/re-enabled by unchecking and re-checking the check box in the Breakpoints view then it will halt correctly at those breakpoints (until another reload of the program). Also "Trouble removing Breakpoint" messages will appear in the console when the breakpoint is disabled.
When a software breakpoint is set, the emulation driver reads the instruction at that location and replaces it with a software breakpoint op-code that will then halt the target when in debug mode. The debugger somewhat hides this from you so you can still see the original disassembly and/or modify it.
If the application writes a new instruction to the address where a software breakpoint has been set (as in the case of code that is copied from Flash to RAM at boot time), the special halting opcode will be replaced with this new instruction. This effectively removes the breakpoint without the debugger's knowledge. This is why the breakpoints fail to halt, and also why an error is printed when you remove it (as a remove writes the original opcode back, but it checks that the breakpoint opcode is still there first).
This is a limitation of software breakpoints. Since the debugger is not aware of when an application might do this, there isn't much the debugger can do other than detect it well after the fact. If the breakpoint is enabled after the code has been copied from Flash to RAM, then they will work.
The easiest work around is to use hardware breakpoints instead. This is also not intrusive on the target, but most C2000 devices only have two hardware breakpoints available. Devices with the ERAD module have additional hardware breakpoints.
The other option is to set a breakpoint that will effectively tell the debugger what the application is about to do so that the debugger can do something about this. To do this, follow the steps below:
Set a breakpoint right before the code that does the copy from Flash to RAM
Right click on this breakpoint and select properties. Under "Debugger Response->Action", change the value from "Remain Halted" to "Execute Expression (GEL)". A new sub-property should appear named "Expression". Change it's value to "DisableBreakpointsDuringRAMCopy()". Then click ok.
Open the startup GEL file by selecting "Tools->GEL Files" and double clicking on the gel file in there (or you can add a new empty GEL file if you don't have one).
In the editor, add the following text:
GEL_Go( LabelWhereCopyIsDone );
Change "LabelWhereCopyIsDone" to the symbol that's meaningful to your application.
For additional information please refer to this thread: https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/354642/1246978#1246978
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Lori Heustess:
C2000 TI Wiki PagesTI Forum Sitemap
ControlSUITEC2000 Getting Started
CLA FAQsWorkshop Material!
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.