Content is no longer maintained and is being kept for reference only!
For the most up to date PRU-ICSS collateral click here
This arcticle is part of a collection of articles describing software development on the PRU subsystem included in OMAP-L1x8/C674m/AM18xx devices (where m is an even number). To navigate to the main PRU software development page click on the link above.
There are currently no debugger tools for PRU code. For example, you cannot set breakpoints in PRU assembler code using CCS or some other GUI. However, there are ways to debug PRU code in the system.
Place "printf" statements
Insert debug instructions for writing to known values to known memory locations. Under CCS you can halt the processor to examine these memory locations for changes. If possible, the DSP which loaded and started the PRU code could contain real printf statements to report the changes in the debug memory location that the PRU has modified.
Trigger debug interrupts
Similar to the printf idea, but instead of the DSP polling memory location for modification made by the PRU, the PRU interrupt controller and the DSP interrupt controller can be setup so that specific PRU events can be fired by certain parts of the PRU code. ISRs on the DSP side can then indicate to the user that the PRU events were seen. This is more complicated than the first debug recommendation, but it does allow the DSP to be running it's own code for the majority of the time. This could be important when the DSP and PRU are working in conjunction to accomplish some task.
Use PRU General Purpose Outputs (R30)
Register R30 of the PRU can be used to set values on external pins of the device. If these pins are easily monitored, one can use an oscilloscope or multimeter to see changes and make conclusion about the PRU code's progress.
Iterative debugging using dummy loops
You can insert dummy while(1) loops into the PRU code and then verify that the PRU program counter (readable in thePRU status register) points to the loop to verify that the code before the loop is getting properly executed. The listing file generated by the PASM tool should be used to determine the correct program counter location. At this point, the PRU control register can be used halt the PRU and the debug registers can be used to examine the state of the PRU's internal registers.