• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 331 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28035: F28035 SPI issue a certain delay (us) between the two times/Command, and the CS bus will be abnormally pulled high

Shaoxing Ke
Expert 3590 points

Part Number: TMS320F28035

Tool/software:

Hi Experts,

When the 28035 chip SPI module is operating external flash expansion, the instruction + address or instruction + data is split into two times and sent from the host to the slave. There is a certain delay (us) between the two times, and the CS bus will be abnormally pulled high, causing the flash to mistakenly interpret one instruction as two instructions. And then SPI communication issue happen during F28035 devices. Could you figure out why delay us between two command here? Why CS signal pull low here?

Greatwall SPI issue.pptx

  • 0
    TI__Genius 11076 points

    Hello,

    This appears to be an issue with the FW control of the CS pin, which is also referred to as the STE or PTE pin in C2000 documentation. Without any details of that control (such as what TI example it is based on, if any), I can only make an educated guess.

    1. If the FW uses the SPISTE functionality of the C2000, then the SPI peripheral should automatically control the STE signal, pulling it low at the start of a transaction and high at the end. To fix this, I suggest not using the SPISTE pin, and instead manually configuring a CS pin to account for this special case.
    2. If the FW manually controls a GPIO to act as the CS pin, then the FW needs to be adjusted such that the GPIO is not automatically pulled high after this instruction.

    As for the delay, I have no way of knowing based on this information, unfortunately. I'd suggest looking at the FW and determining whether the function to write to the SPI is tied to a trigger with a set period, perhaps.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    TI__Expert 3590 points

    Hi Jason,

    Customer used GPIO19 to control CS signal, this issue could be solved, but if they used Option1 the FW uses the SPISTE functionality of the C2000, if the two command delay too long, CS will pull high as shown Figure.1. Could you confirm the SPI module will automatically recognize that if no instructions are received for a long time, the CS pin will automatically be pulled high? Thanks.

  • 0 in reply to Shaoxing Ke
    TI__Genius 11076 points

    Referring to the device TRM SPI section, section 11.3.2 Master Mode:

    The C2000 is set up to automatically stop SPICLK after communication, and should automatically control SPISTE accordingly.

    If the user is not already utilizing the SPI Tx FIFO buffer, I would recommend that they do so, as the TRM excerpt above describes this functionality changing this behavior.

    Let me know if this is helpful.

    Regards,
    Jason Osborn