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.

TMS320F28335 SPI TXBUF drives chip select ?

Other Parts Discussed in Thread: TMS320F28335

Hello everyone,

On a custom board I have a TMS320F28335 micro controller and a flash SPANSION S25FL512S

The two devices are connected through SPI

The F28335 is configured with CPOL = 1 CPHA = 0 ; FIFO disabled ; interrupts disabled ; 8 bit mode for CHAR

My goal is to read the id of the flash to make sure everything is going well

Here's in pseudo-code what I do
1 - Drive CS low (STEA) = 0
2- write the command read id RDID 9F to TXBUF
3- wait for the INT FLAG to be 1
4- dummy read the RX BUF to clear the flag
5- dummy write 0 to TXBUF to get the data from the slave
6- read RXBUF
7- Drive CS high = 1

Now what I see on the oscilloscope is that as soon as (2) is executed, CS goes back to HIGH
(on its own! the code never asks it to do it)

Is there a setting (to disable this behavior) that I missed ?

Regards,
Clement

  • Clement,

    the C2000 SPI drives the SPISTE pin active when a word is transferred from the SPITXBUF to the SPIDAT shift register. It will go inactive after the word is transmitted if there is not another word ready to be transmitted. This is not controllable by the application.

    The best way to accomplish this without FIFO is to use a custom GPIO to emulate the CS. Drive it active before you write to the SPI, and then Drive it inactive when all transmissions are complete. You could use the same pin as SPISTE, just reconfigure it to be GPIO rather than the SPI function since you already have a custom board laid out.


    Thanks,
    Mark
  • Thank you for your answer and the suggestion that I'll follow.

    Why is it NOT written anywhere in the SPI documentation for this processor ? or did I miss it ?

    Regards,
    Clement

  • Looking at SPRUEU3, SPI User Guide for the 2833x/2823x devices:
    Section 1.3.2.1 Master Mode, the last paragraph states this information. For Slave mode operation, the last paragraph of 1.3.2.2 contains similar information. Other than that, there is not a whole lot of information. I will see if i can get this updated in a newer revision of the doc.

    Thanks,
    Mark
  • OK it is written
    "In a typical application, the SPISTE pin serves as a chip-enable pin for a slave SPI device. This pin is
    driven low by the master before transmitting data to the slave and is taken high after the transmission is complete"

    I've read it twice today (before your first answer), even read it with a colleague.
    What we understood from the paragraph was that in a typical app the USER drives the CS low before transmission and high after.
    Instead of "the chip automatically drives CS low ... "

    It could be updated with a clearer wording yes.

    Clement
  • Yes thank you. We will get this clarified.

    Also in the datasheet, Figure 6-18 "SPI Master Mode External Timing" has footnote A: "In the master mode, SPISTE goes active 0.5tc(SPC) before valid SPICLK edge. On the trailing edge of the word, the SPISTE will go inactive 0.5tc(SPC) after the receiving edge (SPICLK) of the last data bit, except that SPISTE stays active between back-to-back transmit words in both FIFO and non-FIFO modes."

    Figure 6-20 "SPI Slave Mode External Timing" has the footnote C: "In the Slave mode, the SPISTE signal should be asserted low at least 0.5tc(SPC) (minimum) before the valid SPI clock edge and remain low for at least 0.5tc(SPC) after the receiving edge (SPICLK) of the last data bit."

    At least in master mode, the note could be a little bit more explicit that the SPI module will drive the SPISTE pin.

    -Mark
  • OK it's all good now (I use the GPIO pin dedicated to CS as a true GPIO pin)

    The WRITE and READ commands work as expected and CS is driven as wanted.
  • Glad to hear that everything works as expected.

    I will file a ticket to make sure that the docs are updated to be more clear.

    Regards,

    Mark