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.

SIMPLELINK-MSP432-SDK: Error in STE(Slave Transmit Enable) signal using TI Driver SPI (4-pin configuration)

Part Number: SIMPLELINK-MSP432-SDK

Hi,

We are having a problem with the STE signal in 4 wire mode running the SPI at 12 MHz, the MCLK at 24MHz and SMCLK at 12 MHz. 

Our setup is as follows:

  • Custom board with the MSP432P4111 and an external flash IS25LP032 from ISSI.
  • No more devices connected to the SPI bus.
  • Code Composer Studio version 10.2.0.00009, with Simplelink SDK version 3_40_01_02 and TI v20.2.5.LTS compiler.
  • The application calls SPI.h functions of the TI SPI driver (pointing to SPIMSP432DMA.c functions).

What we see in the logic analyzer is that after eight SPI clock pulses the next clock pulse (9th) is stretched and at the same time the STE signal goes high in some cases, which results in a loss of communication with the external flash.

If we decrease the SPI frequency to 6 MHz, with the MCLK at 24MHz and SMCLK at 12 MHz it works fine.

Also, if we have SPI frequency at 12 MHz, the MCLK at 48MHz and SMCLK at 24 MHz it also works fine.

We have reproduced this in an attached example project that tries to read the flash ID register and then writes a page, reads it and checks the read values in a loop.

The following image shows the error: The MSP432 writes 0x9F (JEDEC_IC command) in the MOSI line, and it expect to read 3 bytes corresponding to the flash ID of the chip (0x9D, 0x60, 0x16), but only receives the first byte (0x9D).

 

 

And the following is the expected result, captured with SPI at 6MHz, in which the STE signal remains low for all the duration of the transfer, and the clock pulses are not stretched:

 

 

- Why does the STE signal go high in the middle of the transaction at 12 MHz, and how can we resolve this error?

We believe that the clock stretching happens due to the DMA interrupt having to pass the byte to/from the SPI bus to memory, is that true?

Thank you very much for your kind help, 

Alvaro

  • Hi Alvaro,

    You say that when SPI is at 12 MHz and SMCLK is at 24MHz it works as well, I'm curious if you lowered the speed to 6MHz SPI and 6 MHz SMCLK if you'd run into the same issue. I'm suspecting that there is a process where some drift/delay happens due to code and this is causing the SMCLK and SPI to get out of sync. You aren't seeing this when the SMCLK is twice as fast as the SPI so, if you could try testing around to see if this issue only happens when they run at the same frequency, that could help confirm the cause.

    Also, if you have any triggers/interrupts in the code, are these triggers/interrupts happening and then the SPI issue appears?

    Regards,

    Luke

  • Hi Luke,

    Thanks for your reply. With the SPI at 6MHz and the SMCLK at 6MHz it doesn't work either.

    There are no other trigger/interrupts in the example project.

    What is the criteria followed by the TI HW driver to move the STE line?

    Best,

    Álvaro

  • 4-wire+UCSTEM isn't really suited for your NAND chip. STE is normally de-asserted between bytes [Ref TRM (SLAU356I) Fig 25-4], and your slave wants /CS to be asserted for the entire transaction.

    I've read hints in the Forum that STE will not de-assert between bytes as long as the "pipeline" (TXBUF) is kept full. (This seems to be your case -- slowing the SPI down allows the CPU to keep up.) I've never experimented with this since such behavior is not something I'm ready to bet-my-project on.

    I've always used 3-wire with /CS on a separate GPIO. I'm not very familiar with TI-Drivers, so I don't; know exactly how to do that. Luke, do you know?

  • Thanks Bruce,

    When we detected this issue we changed to 3-wire configuration and it works well. Now we understand why the 4-wire didn't.

    Best,

    Álvaro