• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 83 subscribers
  • Views 332 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.

TMS320F28P650DK: How to set up a UARTB peripheral to be driven by CPU2

Cary Sjolander
Prodigy 55 points

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: C2000WARE

Tool/software:

We have a working prototype using UARTB with a DMA running on CPU1, full duplex.
When I try to move the code over to cpu2 I cannot get it to work.
I do not see any DMA interrupts, RX or TX.
Also peculiarly, when looking at the UARTB registers during run-time debug, all the values are 0.
My first thought is that either initialization is not being executed, and/or the UARTB registers are not writable from CPU2.

I have stepped the code through board.c uart init and it seems to be running the expected init code.

Also I have confirmed Peripheral enables and R/W access via CPU and DMA.

Are there any common considerations that I might be missing?

Any help would be much appreciated!

  • +1
    TI__Mastermind 27500 points

    Hello,

    To clarify, are you allocating UART to CPU2? The UART peripheral has to be allocated to CPU2 using CPU1.  Are you doing this in your code? This code has to run on CPU1 which configures the Clock, pins and then allocates the peripheral to CPU2. After this, the CPU2 can start using it.

    You should be able to refer the existing dual core example for MCAN located at  <C2000Ware>\driverlib\f28p65x\examples\c28x_dual\mcan\  (mcan_cpu1_allocate_to_cpu2) and update it for UART.

    Please let me know if this changes the behavior you see.

    Best Regards,

    Allison

  • 0
    Prodigy 55 points

    Thank you for pointing me to a working example.

    //
    // Allocate Ethercat to CPU2
    //
    SysCtl_selectCPUForPeripheralInstance(SYSCTL_CPUSEL_MCANA, SYSCTL_CPUSEL_CPU2);

    I had the feeling I was just missing something...

    Another case where relying on SysCfg might not be the best strategy!