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.

TMDSIDK572: SPI timing delays

Part Number: TMDSIDK572

Hi everybody,

We are working with the TMDSIDK572, Processor SDK RTOS 06_03_00_106 and we are having some troubles using the McSPI2 channel 0 through the Low Level Driver provided by TI in pdk_am57xx_1_0_17.

We are setting up a 48-bit transfer within a frame, 3 words of 16 bits.

We see there is a lot of time between the CS goes low (inverse polarity) and the SCLK first clock, it’s about 900 ns. However, the TCS0 field of MCSPI_CHxCONF is set to 0, which means just half a cycle. We are working at 24 MHz, but we’ve experienced the same result with lower working frequencies:

 Then we suffer a 2.5 µs delay between words of the same transfer:

 At the end of the tranfers, pretty much the same as at the beginning, but this time it’s the double, about 1.8 µs:

 And finally, another delay between the end of the first transfer and a consecutive one (the call to MCSPI_transfer is the only instruction of a for loop):

 So, a transfer that would need just 48 clocks + half a cycle at the beginning + half a cycle at the end should take about 2.05 µs (49 clocks / 24MHz), but it’s taking 900 ns at the beginning + 2x2.50 µs inter words + 2.05 µs (the real transfer with SCLK) + 1.8 µs at the end + 6.64 µs to begin the next frame = 16.39 µs, 8 times slower:

 

I’ve tried setting manually the Turbo Bit of MCSPI_CHxCONF as our configuration is single channel, but the result doesn’t change.

We’ve tried also switching from polling mode to interrupt mode, and it’s even worse!

 

The delay between words decreases a lot (300 ns), but the delay at the beginning, the delay at the end and the time between consecutive transfer increase dramatically making the overall time go from 16.4 µs to 20 µs.

 

I’ve reviewed the TRM and the SDK RTOS, but I can’t find the reason for all these delays and we need a very fast throughput in our system.

Does anyone have an idea of what can I be setting wrong? We know that the LLD allows overriding the MCSPI_transfer function but we want to avoid this option as much as possible, we prefer using the drivers provide by TI.

 Here you’ll find the code snippets of our configuration for McSPI2:

 And the consecutive transfer, called within a task:

´

With all this, MCSPI_CHxCONF value at 0x4A09A128 is 0x18E07C5 which means using buffer for Tx and Rx, TCSO of 0.5 clock cycle, Turbo to maximize the throughput, no DMA used, Transmit-and-receive mode, 16 bits word length and 24 MHz.

And MCSPI_MODULCTRL at 0x4809A128: 0x00000001 which means no initial delay, master, 4 pin mode and single channel.

Thank you in advance for your support.

  • Hi,

    MCSPI_transfer() will call MCSPI_primeTransfer_v1() in ~\pdk_am57xx_1_0_17\packages\ti\drv\spi\src\v1\SPI_v1.c.

    In MCSPI_primTransfer_v1() as shown below, CS line will go low after McSPIChannelEnable(). However, the data will be sent inside MCSP_xferSetup_v1().

    /* Enable the McSPI channel for communication */
    McSPIChannelEnable(hwAttrs->baseAddr, chNum);

    /* setup transfer mode and FIFO trigger levels */
    MCSPI_xferSetup_v1(mcHandle, transaction);

    I think the delay may be introduced inside MCSPI_xferSetup_v1() for setting up the transfer.

    Regards,
    Stanley