• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 202 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28377D: Illegal ISR when executing code in RAM

Arthur Ohl
Prodigy 125 points
Part Number: TMS320F28377D

Hello,

I'am working on a complex project using both CPU1 and CPU2 to control a DC/DC converter. 

CPU1 is dedicated to regulation, whereas CPU2 is dedicated to communication with other parts of the system.

To increase even more regulation period execution, I decided to transfer the code for my regulation on the CLA of CPU1.

By doing this, I had to rewrite my drivers (PWM) to allow compilation for CLA. It forced me to change the CMD file of both processors to define CLA sections (code and program).

As LSRAM was used to execute TI functions (including CRC), they were not enough space in this RAM to place CLA and code and program.

So, I had to map TI functions, .ebss .esysmem and .cio in the GSRAM. After doing this, I observed an execution problem on the CPU2 when debugging. 

During initialization, I use the VCU CRC module and it goes in Illegal ISR interrupt.

The same code was perfectly working before.

Could you please help me with this issue ?

I can provide only small part of source code for confidentiality.

Thank you,

Arthur

  • +1
    TI__Mastermind 32425 points

    Hi Arthur,

    Note that the GSRAM is shared between CPU1 and CPU2. You can assign an owner for each GSRAM and only the owner core has write access to it. Ownership needs t be assigned  by CPU1 core.

    Another point to be noted is that the .stack section has to be linked into the low 64K of data memory. The SP is a 16-bit register and cannot access addresses beyond 64K.

    Regards,

    Veena

  • 0
    Prodigy 125 points

    I think I solved the problem by moving the CLA memory access configuration (LSMSEL register) at the beggining of my initialization procedure.