• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 917 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.

MIBSPI Ram Access while transfer in progress

KARTHIKEYAN RAJAMANICKAM
Genius 11645 points

Other Parts Discussed in Thread: TMS570LC4357

Creating this as per request from Gael due to issues in creating a new post.

Gael pls add more details

When a master (DMA or CPU) writes into the TX RAM buffers while MibSPI is in transmission, the MibSPI has some trouble sending or receiving correctly the frames. Precision: in my experiments, there were no accesses from the CPU and the MibSPi to the same buffer at the same time).

  • 0
    Expert 1020 points
    Hi Karthik and thank you for posting the subject here for me.

    Here are some details about the situation:

    I'm using a TMS570LC4357 and I'm experiencing something quite strange.

    I use the MibSPI5 as a slave, connected to an external CPU (Qorivva family) which is the master and triggers the communication every millisecond. On the SPI (seen with an oscilloscope) the master activates the Chip select and sends 85 frames of 16 bits. The TMS responds with data from its buffers.

    The transfer takes approximately 130 microseconds and is re-triggered 1 ms later, in a loop (time between two CS assertion equals 1130 microseconds).

    To send the more up to date data, the Chip select is connected to GIOA[0] and an FIQ is triggered when the CS is asserted to update the MibSPI buffers 2 to 86 (buffers 0 and 1 contains zeroes to let the TMS enough time to write the first data). A time marker is taken in that function to mark the beginning of the transfer.

    At the end of the transfer, a TG finished interrupt is triggered to extract data received from the CPU. In that function, I read the MIBSPI5FLG register to detect errors and I compute the time elapsed since the beginning of the transfer.
    In that scenario:

    - from the CPU point of view: I can see correct data are received sometimes, but sometimes only zeroes are received
    - from the TMS point of view: I notice that sometimes the time elapsed equals 1260 microseconds instead of 130 microseconds, and when that occurs, the MIBSPI5FLG indicates a "bit error".

    Then, when I disable the FIQ (I set the buffers with static data), the CPU receives correctly every word, each time the communication is triggered (every millisecond). From the TMS point of view, the delta time is always 130 microseconds and no bit error are detected.


    With that experiments, I would make the hypothesis that: when an SPI transfer is running, writing into the buffers may cause an incorrect behavior in the SPI kernel, which misses one or more clock pulse.

    Does anyone did experiment this problem? Can TI make a experiment on his side to try to reproduce the problem? Did I miss something in the reference manual that would solve my problem?

    Thanks for your support,
    Best regards,
    Gael
  • 0 in reply to Gael Le Moing
    TI__Mastermind 49120 points

    Hi Gael,

    I am working on this report along with our SPI expert. From what I understand, you have allowed the transmission time of two 16-bit buffers as the time available for the CPU to write the remaining 83 buffers. After this point there is a race between the CPU writing to the buffers and the MibSPI transmitting them. I think there will be a case where the CPU is updating a buffer that is actually being transmitted by the MibSPI transmit state machine, and this will cause a bit error.

    The MibSPI TX RAM is configured as a strongly-ordered memory by default. This means that the CPU writes to this memory are not buffered and must complete before another access is made to memory. Note that each peripheral RAM access could take as many as 24 CPU cycles (am confirming this number with the design team). This could easily be the bottleneck that you are running into.

    Regards,
    Sunil

  • 0 in reply to Sunil Oak
    Expert 1020 points

    Hi Sunil,

    Thank you for your answer.

    First I need to correct one thing in what I described:

    Sunil Oak said:
    From what I understand, you have allowed the transmission time of two 16-bit buffers as the time available for the CPU to write the remaining 83 buffers.

    >> In fact, it is only one 16-bit word. 

    The complete transfer takes about 130 µs to transfer 85 frames. I measured the time needed for the FIQ interrupt triggered by the Chip Select assertion, and this FIQ takes about 15µs to update buffers 1 to 84 (the first one - 2 dummy bytes - being transmitted are not written again). That measure was seen with an oscilloscope using a GPIO in the FIQ.

    Sunil Oak said:
    After this point there is a race between the CPU writing to the buffers and the MibSPI transmitting them.

    >> That's why I have defined a 2-bytes dummy word at the beginning of the transaction. From this point, and with the FIQ measured time and the complete message transmission measured time, I guess the race is clearly won by the CPU than by the MibSPI, except maybe if the FIQ starting time is variable (time between chip select assertion and FIQ routine first instruction execution). Do you think that is posible? If so, do you have an idea of how big the jitter could be for an FIQ handling?

    Sunil Oak said:
    The MibSPI TX RAM is configured as a strongly-ordered memory by default. This means that the CPU writes to this memory are not buffered and must complete before another access is made to memory. Note that each peripheral RAM access could take as many as 24 CPU cycles (am confirming this number with the design team). This could easily be the bottleneck that you are running into.

    >> Ok, then this would mean that the CPU has the priority over the MibSPI when accessing to the buffers RAM, right? In that case, is it possible to configure anything to change that priority to prioitize the MibSPI over CPU?

    Thank you for your answers,

    Gael