MSPM0G1518: SPI peripheral short bit then bit shifted

Part Number: MSPM0G1518

I have a SPI peripheral configured to use two channels of DMA to transmit and receive. I'm consistently seeing a very short SPI transmit bit then the SPI perpheral appears to have bitshifted.

image.png I checked the errata and there's nothing in there that would describe this bug. My first question is why is this happening? The second question is is the only way to recover to reset the SPI peripheral on CS inactive?

  • Hi Rob,

    The short pulse/glitch you are observing could be caused from noise. Do you have the recommended decoupling capacitors on VDD and close to the VDD pin? As for the layout, I would recommend ensuring that there is a proper ground plane and minimize the trace lengths for high-speed signals.

    Are you able to observe the analog signal? 

    I would suggest setting the CSCLR bit such that shift register counter gets reset once the CS line goes inactive:

    You can also implement error checking, if needed.

    Best,

    Owen

  • Hi Owen,

    The short pulse isn't noise. The first two bytes of the MOSI and MISO should be identical - 0xAA55. You can see the first byte is correct - 0xAA, but the second byte gets bit shifted to the left after that short pulse and all data thereafter is bit shifted to the left by 1 bit.

    My SPI peripheral is configured for three wire since there's no way to determine when the SPI is selected and deselected and I need to setup my transmit buffers on the deselection to prepare for the next selection event. I'm a little surprised there's no way to use the peripheral ISR to determine when the SPI is selected and when it's deselected.

    Am I correct in the only way to recover from this bit shifted state is to reset the SPI peripheral?

  • Is it always the same bit? You could get this effect from noise on the SCK line, but if so I would expect it to move around. The upper line is MOSI and the lower line MISO?

    This is the kind of thing CSCLR was designed to repair, though only at the end of the transaction. If you can't use CSCLR, I suppose you'll need to reset the SPI unit. 

  • Hi Rob,

    Thanks for the clarification.

    The short pulse is interesting, and makes me want to believe it is an issue with the timing of the DMA transfers/filling the FIFO.

    You can use another GPIO pin to monitor the CS line to determine if the peripheral is currently selected or deselected. Another approach would be to use the DL_SPI_IIDX_IDLE interrupt to determine if the FIFOs are ready to be filled.

    If you are using 3-wire SPI and can't use CSCLR functionality, then resetting the SPI peripheral would be only way to recover the shift register counter.

    Best,

    Owen

  • Ok, I have a little more information and I really appreciate all the support from TI.

    In the above attached capture the SPI controller in the top traces and SPI peripheral is in the bottom traces. The SPI peripheral is the one that's bit shifting. Here's what I've found so far:

    1 - If both SPI buses are running and clocking data in/out at approximately 1Mbps the SPI peripheral bit shift happens consistently and very early.

    2 - If I disable the SPI controller, but keep everything else (1Mbps SPI peripheral) the bit shift never happens.

    My next step was to put an analog probe on the SPI peripheral clock line. This actually fixed my bit shift issue so this issue is certainly a signal integrity issue where I presume one or more of the SPI controller's signals was getting on the SPI peripheral's clock and glitching the SPI peripheral. We've since added series resistors to the SPI lines.

    Thank you again to TI for all of the support.

    Future MSPM0 feedback - it would be amazing to be able to use the SPI peripheral in 4-wire mode so I can take advantage of the CSCLR functionality and have the ability to be interrupted when the SPI is selected and deselected. Unless I'm missing something, there's presently no way to know when the SPI is selected or deselected aside from switching to 3-wire mode, losing the CSCLR functionality, and using the CS pin as a general GPIO.