SPRUII0F May 2019 – June 2024 TMS320F28384D , TMS320F28384D-Q1 , TMS320F28384S , TMS320F28384S-Q1 , TMS320F28386D , TMS320F28386D-Q1 , TMS320F28386S , TMS320F28386S-Q1 , TMS320F28388D , TMS320F28388S
Insert a CLA breakpoint (MDEBUGSTOP instruction) into the code where the CLA is to halt, then rebuild and reload the code. Because the CLA does not flush the pipeline when in single-step, the MDEBUGSTOP instruction must be inserted as part of the code. The debugger cannot insert the MDEBUGSTOP instruction as needed.
If CLA breakpoints are not enabled, then the MDEBUGSTOP instruction is ignored and is treated as a MNOP. The MDEBUGSTOP instruction can be placed anywhere in the CLA code as long as the MDEBUGSTOP instruction is not within three instructions of a MBCNDD, MCCNDD, or MRCNDD instruction. When programming in C, the user can use the __mdebugstop() intrinsic instead; the compiler makes sure that the placement of the MDEBUSTOP instruction in the generated assembly does not violate any of the pipeline restrictions.
Enable the CLA breakpoints in the debugger. In the Code Composer Studio™ IDE, this is done by connecting to the CLA core (or tap) from the debug perspective. Breakpoints are disabled when the core is disconnected.
There are three ways to start the task:
Once halted, the user can single-step the CLA code. The behavior of a CLA single-step is different than the main C28x. When issuing a CLA single-step, the pipeline is clocked only one cycle and then again frozen. On the C28x CPU, the pipeline is flushed for each single-step.
Run to the next MDEBUGSTOP or to the end of the task. If another task is pending, the task automatically starts when run to the end of the task.
If the CLA gets caught in an infinite loop, use a soft or hard reset to exit the condition. A debugger reset also exits the condition.
There are special cases that can occur when single-stepping a task such that the program counter, MPC, reaches the MSTOP instruction at the end of the task.
If single-stepping or halted in "task A" and "task B" comes in before the MPC reaches the MSTOP, then "task B" starts if continuing to step through the MSTOP instruction. Basically, if "task B" is pending before the MPC reaches MSTOP in "task A" then there is no issue in "task B" starting and no special action is required.
In this case, if single-stepped or halted in "task A" and the MPC has reached the MSTOP with no tasks pending. If "task B" comes in at this point, "task B" is flagged in the MIFR register but "task B" can or cannot start if continuing to single-step through the MSTOP instruction of "task A."
Depending on exactly when the new task comes in, to reliably start "task B", perform a soft reset and reconfigure the MIER bits. Once this is done, start single-stepping "task B."
This case can be handled slightly differently if there is control over when "task B" comes in (for example, using the IACK instruction to start the task). In this case, the task is single-stepped or halted in "task A" and the MPC has reached the MSTOP with no tasks pending. Before forcing "task B," run free to force the CLA out of the debug state. Once this is done, force "task B" and continue debugging.
In the Code Composer Studio™ IDE, disable the CLA breakpoints by disconnecting the CLA core in the debug perspective. Make sure to first issue a run or reset; otherwise, the CLA is halted and no other tasks start.