NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

Control Law Accelerator (C2000 CLA) Debug on CCS FAQ

From Texas Instruments Wiki
Jump to: navigation, search

x x x x x x




The CLA FAQs are being migrated to E2E FAQs. Please refer to https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/786227

As the FAQs are migrated they will be deleted from the wiki.


x x x x x x





This topic is a list of frequently asked questions that users have when debugging the C2000 Control Law Accelerator (CLA) in Code Composer Studio V3.3.


Contents

Other Resources

x x x x x x




The CLA FAQs are being migrated to E2E FAQs. Please refer to https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/786227

As the FAQs are migrated they will be deleted from the wiki.


x x x x x x




Training Videos

Frequently Asked Questions

Workshop Material

Section 9 of the Piccolo Multi-day workshop is dedicated to the Control Law Accelerator












CLA Registers

Q: How can I view the CLA registers?

CCS v5: Click on the CLA debug session and then select: View->Registers. The CLA registers will be shown in the register window.
CCS v4: Click on the CLA debug session and then select: View->Registers. The CLA registers will be shown in the register window.
CCS v3.3: In the CLA debug window you can view the CLA registers under View->Registers->CLA. Also since they are memory mapped you can add them to the watch window of the main CPU debugger window.

Q: I can't figure out how to view the CLA result registers in floating-point format?

CCS v5: Right click on the "value" in the register window. Select "number format" and then "float"
CCS v4: Right click on the "value" in the register window. Select "format" and then "float"
CCS v3.3: This has been submitted as an enhancement request. For now you can add the result registers to the watch window using the name with CLA in front. For example: CLA_MR0 or CLA_MR3. In the watch window you can change the type to 32-bit float. Update: This was fixed in build 14 of the evaluation tools.

Q: Why do the CLA registers all read back 0?

The CLA registers are protected by the Code Security Module (CSM). Make sure the CSM is unlocked to view the registers.

Q: Why can't I edit the CLA execution registers (MPC, MAR0, MAR1, MR0-MR3...) in the debugger?

These registers are read only by the main C28x CPU. Since all debug accesses are handled by the main CPU, you can not edit them in the debugger.

Q: What is the difference between the MPC and the "core PC" in the CLA debug window?

MPC is the register itself; it is an offset from the beginning of the CLA program space. MPC points to the instruction currently in the D2 phase of the CLA pipeline.
Code Composer Studio also requires a "core PC" register to manage and keep track of the disassembly window and source code stepping. You will notice that the "core PC" corresponds to the actual memory location. For example, if the CLA program space begins at 0x9000 and MPC is 0x0120, then the "core PC" will be 0x9000+0x0120 = 0x9120.

Breakpoints, Stepping, Running, Viewing Symbols

Q: I've pressed the step (or run) button in the CLA debug window and CCS issued an error. What is wrong?

It is likely that the CLA is either idle (that is, a task is not being executed) or it is running (i.e. not halted on a breakpoint). In order to issue a "step" or a "run" the CLA should be executing a task (i.e. MIRUN != 0) and the MPC should be halted on a breakpoint (MDEBUGSTOP instruction).

Q: My CLA is idle (MIRUN == 0). How can I start a task while debugging?

Tasks are started in 3 ways. 1) peripheral interrupt 2) main C28x IACK instruction or 3) writing to the MIFRC (force) register.
Probably the easiest way to start a task that you want to single step is writing to the force (MIFRC) register in the debug window. Bit 0 corresponds to interrupt 1/task 1, bit 1 to interrupt 2/bit 2 etc.

Q: In some examples, the C28x starts a task using the function: Cla1ForceTask2andWait(). What does this do?

This is a macro that is defined in the Cla_defines.h file to help while debugging CLA code. There is one macro per task (i.e. Cla1ForceTask1andWait(), Cla1ForceTask2andWait(), etc..).
The macro does the following:
  • Issues an IACK instruction to start the specific task
  • Waits a few cycles (see next question)
  • Polls the MIRUN bit to "wait" until the task has completed.
There are also versions that do not "wait": ClaForceTask1() etc..

Q: I've used the Cla1ForceTask8andWait() macro. The C28x doesn't "wait" and continues execution. What is wrong?

The C28x will poll the MIRUN bit to see if the task is still executing. If the task did not start, then the C28x will continue execution and not wait. If this is the case check the following:
  • The macro uses the IACK instruction to start a task. Make sure you've enabled this feature in the MICTL register.
  • Make sure the interrupt is enabled in the MIER register.
If the task started, but the C28x still didn't wait:
  • In some example code the Cla1ForceTaskxandWait() macro only has two NOP's between the IACK instruction and polling the MIRUN bit. If the 28x polls the MIRUN bit too early it will still see it cleared. To fix this, add an additional NOP before polling the MIRUN bit.

Q: How do I enable and disable CLA breakpoints?

CCS v5.2:
  • In the debug perspective, open the "debug" window (View->Debug)
  • Click on the CLA processor in the debug window. This will automatically switch the context to the CLA debug. Notice in the CLA is "disconnected". This means the CLA breakpoints (MDEBUGSTOP instructions) are disabled and treated as MNOPs by the CLA.
Ccs5 cla disconnected.jpg
  • Select: Run->Connect Target (or right click and select "Connect Target"). This will connect the CLA debugger and enable CLA breakpoints. The status in the debug window will change to indicate the CLA is no longer disconnected. When you connect the CLA, the debugger will automatically connect the C28x as well. This is the desired behavior; to debug the CLA you must have the C28x connected as well.
  • To disable CLA breakpoints you would disconnect the CLA debug window (Run->Disconnect Target or right click and select "Disconnect Target"). In this case the CLA breakpoints will be treated as MNOP (no operation). Before you disconnect make sure to issue a "run". If the CLA doesn't free run before you disconnect, it will stay halted where you left it and no other task will execute.
CCS v4:
  • In the debug perspective, open the "debug" window (View->Debug)
  • Click on the CLA processor in the debug window. This will automatically switch the context to the CLA debug. Notice in the screen shot the CLA is "disconnected". This means the CLA breakpoints (MDEBUGSTOP instructions) are disabled and treated as MNOPs by the CLA.
Cla debugv4 1.jpg
  • Select: Target->Connect Target. This will connect the CLA debugger and enable CLA breakpoints. The status in the debug window will change to indicate the CLA is no longer disconnected. When you connect the CLA, the debugger will automatically connect the C28x as well. This is the desired behavior; to debug the CLA you must have the C28x connected as well.
  • To disable CLA breakpoints you would disconnect the CLA debug window (Target->Connect Target - this option toggles whether you are connected or disconnected). In this case the CLA breakpoints will be treated as MNOP (no operation). Before you disconnect make sure to issue a "run". If the CLA doesn't free run before you disconnect, it will stay halted where you left it and no other task will execute.


CCS v3.3:
Note: in the CCS v3.3 evaluation tools, prior to build 16, disconnecting the CLA window did not disable CLA breakpoints. This has been fixed in build 16.
  • First open the C28x debug window from the debug manager
  • Connect the C28x debug window using the Debug->connect or alt-c command. The C28x must be connected before you connect the CLA.
  • Next open the CLA debug window from the debug manager
  • When you perform a connect (Debug->connect or alt-c) the CLA debug window, it will automatically enable CLA breakpoints. This, of course, assumes that the CLA clock is already enabled. For this reason we have added a CLA clock enable in the OnReset() function of the Code Composer Studio gel file for devices with the CLA. This gel function gets executed each time you reset the device.
  • To disable CLA breakpoints you would disconnect the CLA debug window (debug->disconnect or alt-c). In this case the CLA breakpoints will be treated as MNOP (no operation). Before you disconnect make sure to issue a "run". If the CLA doesn't free run before you disconnect, it will stay halted where you left it and no other task will execute.

Q: How do I insert a breakpoint into CLA code?

Assembly code: First add the MDEBUGSTOP instruction into the code where you would like to halt. Then rebuild and load the code. Remember that the MDEBUGSTOP instruction must not be within 3 instructions (before or after) a branch (MBCNDD), call (MCCNDD) or return (MRCNDD) instruction. When the CLA halts the MDEBUGSTOP instruction will be in the D2 (decode 2) phase of the pipeline. From there you can single step the CLA or run to the next breakpoint or MSTOP.
C Code: Use the __mdebugstop() intrinsic to insert a breakpoint. Then rebuild and load the code. When the CLA halts the MDEBUGSTOP instruction will be in the D2 (decode 2) phase of the pipeline. From there you can single step the CLA or run to the next breakpoint or MSTOP.

Q: Why do I have to rebuild and load my code to insert a CLA breakpoint?

For the C28x main CPU when you insert a breakpoint the debugger will insert an ESTOP0 (C28x breakpoint) instruction on the fly and then replace it with the original opcode after you halt. The C28x pipeline is designed to allow this to occur seamlessly.
The CLA pipeline, however, is simplified when compared to the the C28x pipeline. When the MDEBUGSTOP (CLA breakpoint) instruction is encountered the pipeline halts with the breakpoint in the decode 2 phase of the pipeline. The pipeline is not flushed and the PC is not advanced. Also instructions will not be re-fetched once you begin stepping again. For this reason, the MDEBUGSTOP has to be inserted into the code itself and the code rebuilt.

Q: Can I view symbols in the CLA debug window?

Absolutely!
CCS v5: First click on the CLA processor in the debug window. Then load the symbols using the Run->Load->Load Symbols menu.
CCS v4: First click on the CLA processor in the debug window. Then load the symbols using the Target->Load Symbols menu.
CCS v3.3: In the CLA debug window, use the File->load symbols menu to load the symbols. Another suggestion is to also load the Code Composer project or open the CLA assembly file in the CLA debug window. This way the debugger will show you where you are in the source as you single step. Note: if your code image changes and the symbols move, then then you will need to reload the symbols in this window for them to be correct.

Q: How do I single step or run the CLA?

Once the CLA halts on a breakpoint (MDEBUGSTOP) you can use the normal step and run buttons in the CLA debug window. If you have the source code and symbols loaded you can also use the source single step.

Q: What does Run->Reset->CPU Reset on the CLA debug window do?

This will perform a soft reset of the CLA.
In previous versions of CCS this was debug->reset.

Q: If I halt before an instruction, I have to step the CLA multiple times before I see the result of the instruction. Why is this?

This is due to the CLA's simplified pipeline.
When debugging C28x code, you have noticed that the pipeline is flushed on each assembly single step. This means each instruction is pushed through the whole pipeline so that you see the result of the instruction immediately after you step.
On the other hand, the CLA pipeline moves forward only one cycle every time you step. The instruction indicated by the CLA program counter (MPC) is currently in the D2 (decode 2) phase of the pipeline. If you step once it will move to R1 (read 1). If you step again it will move to R2 (read 2). After the third step it will be in the EXE (execute) phase.

Q: I reset the main CPU and ran. A peripheral or code started a task but the CLA did not stop on a breakpoint. What could be the cause?

When you reset the device, the CLA breakpoints are disabled and the CLA clock itself is disabled. For the debugger to re-enable the CLA breakpoints the CLA clock needs to also be re-enabled. To make this automatic, you can add a statement to enable the CLA clock in the OnReset() function of the GEL file.
Note: Newer GEL files already have this included.

Q: Will the debugger allow lock-step single-stepping of the CLA and the main CPU?

You can single step the main CPU and the CLA separately.







Misc

Q: Is it ok if I load code using the CLA debug window instead of the main CPU debug window?

Yes, although you may see some strange behavior it is nothing damaging to the debug environment. For example the CLA debug window may try to set an end of program breakpoint which it cannot do. In this case it will issue an error. You can change the options in the CLA window to not set breakpoints when you load the program. The CLA debug window may also set its source/disassembly display to the entry point of the C28x code.

Q: The CLA program memory/disassembly window reads back all 0 while the CLA is executing. Why is this?

In most cases you probably won't even notice this. When CLA program memory is mapped to the CLA memory space, a CLA fetch has higher priority than CPU debug reads. For this reason, it is possible for the CLA to permanently block CPU debug accesses if the CLA is executing in a loop. This might occur when initially developing CLA code due to a bug that causes an infinite loop. To avoid locking up the main CPU, the program memory will return all 0x0000 for CPU debug reads when the CLA is running. When the CLA is halted or idle then normal CPU debug read and write access to CLA program memory can be performed.
If the CLA gets caught in a infinite loop, you can use a soft or hard reset to exit the condition. A reset of the main CPU will also exit the condition.