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

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.

TMS320F28379D: CPU cannot operate peripheral registers

Brian Wang0
Expert 5540 points

Part Number: TMS320F28379D

Hi team,

I meet a problem in my customer's system.

In their project, they assigned peripherals SPI, ADC and QEP to CPU2. Take SPI for example, the initialization is shown as below:

However, if I load the program into the flash and execute the code directly, the register is not written as the above code.

In advance, we noticed the registers can be written under the following circumstances:

1) For CPU2, press restart and then run;

2) Execute CPU1 first and then single step CPU2.

I am doubting the reason of this problem is CPU2 writes the register before CPU1 assigns the peripheral. Is their any way to ensure the CPU2 only operates the registers after the assignment?

Besides, what is the exact difference between restart and reset in the CCS window?

Thanks for your supporting.

  • 0
    TI__Guru 54805 points
    The two images you shared appear to be the same, so I'm not sure what you were trying to show.

    CPU2 won't be able to write to the registers until CPU1 assigns control, so if you don't have their execution synchronized such that CPU2 won't reach the code where it configures the peripherals until it has permission, I can see where you could get this issue. For example you could use an IPC flag that CPU2 can poll until CPU1 sets it to let it know it can proceed to peripheral initialization.

    Reset will perform a CPU reset and take you to the start of boot ROM. Restart will take you to your application entry point, bypassing boot ROM. This can make a difference when debugging dual core applications because the CPU2 boot ROM waits for CPU1 to release it from reset. You may notice some of our IPC examples call IPCBootCPU2() to do this. If you aren't doing anything in CPU1 to let CPU2 boot, that could be another reason the registers aren't being configured by CPU2. You completely bypass this when you do a restart with the debugger, but it makes a difference when running standalone from flash.

    Whitney
  • 0 in reply to Whitney Dewey
    TI__Expert 5540 points
    Hi Whitney,

    We did some experiment and our solution is proved to be right.
    All the CPU select operation in CPU1 is moved above the IPC operation to make sure CPU2 only operates the peripherals after the assignment. And the problem is solved successfully.

    Thanks again for your kindly support.
    Regards.