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/AM3358: PRU-ICSS C code issue

Part Number: AM3358

Tool/software: Code Composer Studio

The chip I use is AM3358, the upper ARM core runs the application program, and the bottom PRU core runs
to control the execution program of the peripheral device, and they share data with shareRAM. In the
past, programs in PRU were written in assembler instructions, and run smoothly. Now the PRU program is
rewritten in the same way with the same C language, then compiled in the PRU, and occasionally the
peripherals will stop responding (the probability of error is about 10 times a 1-2 problem), as if the
PRU program has been waiting for what, no longer to execute it.What is the reason for this? in the PRU
compiler, heap size is 0x300,stack size is 0x400.In one experiment,the response was stopped,after 31
hours of operation.What should I do? Thanks!

  • Hi Guohui,

    If I understand correctly, you originally wrote this PRU firmware in Assembly and have ported it to C. There should be no functional difference between the Assembly and C code. However, you’re seeing a different behavior. Is this understanding correct?

    A few other questions—

    1. Were your old Assembly programs developed using PASM or the PRU CodeGen Tools (built into CCS)?
    2. Have you compared the Disassembly from your new code with your original Assembly code?
    3. Can you provide more details about your PRU implementation? This will help me better advise how to debug.

    Regards,
    Melissa
  • Yes,you are right.

    My old Assembly programs develpoed using PASM.

  • Hi Guohui,

    It is difficult for me to comment without additional details about your project. However, here are a few debug suggestions:

    1. Compare the Disassembly code between your new (C-based) and old (assembly-based) firmwae for differences.

    2. Try to figure out the section of PRU code has recently executed when the peripheral stops responding. This may give you some clues about what's not happening as expected. You may be able to observe what's happening on the peripheral I/Os right before it hangs and infer what's recently happened. Or, pause the PRU core after it hangs and based on the line of code it's executing, what's stored in memory, etc. infer what has recently executed. Another tactic is to add some "debug code" into your PRU firmware. For example, you can arbitrary assign a number to major sections in your code and have the PRU write this number to memory (i.e. DRAM) when that code section executes. Then, when the peripheral stops responding, you can pause the PRU and see what numbers are stored in memory-- thus, identifying what section of code was last executed.

    Regards,
    Melissa