• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 81 subscribers
  • Views 766 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.

TMS320F28379D: CLA access to SPI

Alex Roytman
Prodigy 30 points
Part Number: TMS320F28379D

Hello all,

I have code that works on CPU2. It interfaces SPI A & B.

There are some GPIO as well used as chip selects, transfer enable, etc. for devices connected to SPIs.

I moved that code to CLA on CPU2.

The problem is - now nothing is read back from SPI RX, it always returns zero.

I moved the code that manipulates the relevant GPIOs as well, set the ownership to of SPIs to CLA.

CLA is the secondary master (not DMA).

No interrupts are (were) used. The code waits until SpixRegs.SPISTS.bit.BUFFULL_FLAG is zero before writing.

Then waits until SpixRegs.SPISTS.bit.INT_FLAG is 1.

All writes/reads are of single 16 bit word synchronized by timer. 

The number of iterations to test the INT_FLAG was limited to 15. After moving to CLA it started to timeout.

Increasing the limit to 200 did not solve the time out problem (this is arbitrary value, need to retest).

However, the data returned is zero.

SPI status register is zero after timeout. Is it possible that I am missing some other initialization?

Is it possible that CLA runs at clock different from CPU (hence, the timeout)?

Is there a need for EALLOW to access GPIO/SPI registers? 

Any other thoughts/pointers are appreciated.

Thank you

  • 0
    TI__Mastermind 32995 points
    The CLA runs at the same frequency as the C28 which is SYSCLK.

    None of the SPI registers are EALLOW or MEALLOW protected so that isn't the issue either.

    Can you try writing to a SPI register and seeing if the write goes through. If it does then you have properly configured access. If it doesn't, you may have a problem with the permission of the CLA to the SPI.

    If you have done this right, then the issue may be your SPI connection or implementation of the communication.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 30 points
    Thank you very much for your help.


    Scope shows that communication occurs, but, busy waiting on Spix.SPISTS.bit.INT_FLAG times out after 200 iterations.
    Interrupts are not used and this way works ok when code runs on CPU2. In this case busy wait limited to 15 iterations is enough to get a response.


    Regarding EALLOW or MEALLOW: is this required for GPIO registers? Is synchronization/serialization/mutual exclusion needed in case CPU & CLA both access there registers?


    I work on bare metal, i. e. no operating system.


    Thank you
  • 0 in reply to Alex Roytman
    TI__Mastermind 32995 points
    You usually have to designate which core is the master so there should not be any race conditions, since there can only be one owner.

    Please see the TRM to determine if you need to use EALLOW/MEALLOW. We provide all that information so we don't have to look it up and post it here every time.

    Hope this helps,
    sal