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.

TMS570LS1224: Generating a 32 bit continuoious bit stream from the SPI interface

Part Number: TMS570LS1224

Tool/software:

Hi,

We been successfully using a TMS570LS1224 device for many years in our products. To date we have used the SPI ports in 8 or 16 bit mode.

We now have a requirement to generate a 32-bit continuous serial data word, however the device only supports 16 bits per word.

We have tried setting the device onto 16-bit mode and loading two 16-bit words back-to-back (ie not waiting for TX to complete before loading the next word).

We can get the 32 bits out of the device at the required rate (2MHz), but there is a small delay inserted between the first and second 16-bit word (approx. 60ns).

This is causing us an issue with our receiving device as the inserted gap is causing data corruption.

is there any way to reduce this gap / reload time. I assume this is an internal SPI hardware fetch time, when loading the next data word from the buffer?

We currently have the device configured as follows:-

SPI Channel           = SPI3
Write Delay             = 0;
Parity Polarity         = EVEN (0);
Parity Enable          = ENABLE (0);
Wait On Enable       = NO_WAIT (0)
Shift Direction          = MSB_FIRST (0);
Clock Polarity           = POLARITY_LO (0);
Clock Phase            = NO_DELAY (0);
Bit Rate                   = 2MHZ;
Data Word Length   = 16U;

We can resolve this using external shift registers, but had hoped to utilise the internal SPI for this if possible as we are very short on real estate on our board.

Any advice you can provide would be greatly appreciated.

Kind regards,

Paul

  • Hi Paul,

    We can get the 32 bits out of the device at the required rate (2MHz), but there is a small delay inserted between the first and second 16-bit word (approx. 60ns).

    This is causing us an issue with our receiving device as the inserted gap is causing data corruption.

    Are you sure this 50ns extra period causing the issue?

    I am also suspecting this in between the transfers the CS line will get toggle like as show below:

    To prevent this, we should use CSHOLD bit:

    If it is not due to chip-select inactive between the transfers then try to make sure you configured these delays as zero like shown below:

    If these delays already zeros, then maybe we cannot further decrease this 50 to 60nS, however try also with DMA once instead of manual CPU write.

    --
    Thanks & Regards,
    Jagadish.