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.

TCAN4551-Q1: SPI Chip Select requirement

Part Number: TCAN4551-Q1

If I have one processor as the SPI master, and the TCAN4551 as the slave, do I need to raise the CS line after each transaction? 

Can I lower the CS line before the first ever transaction, and then leave it low forever?

Does this behaviour require a different clock polarity? e.g. if the internal clock works on the very first lowering of the CS, but I don't lower it around each transaction, will there be a problem for the device receiving data?

Thanks in advance.

  • Ed,

    The details for SPI communication start on page 39 of the datasheet, but for the CS line, I believe you'll need to bring it back high after every SPI transmission. 

    I've assigned this to a device expert who will respond accordingly.

    Regards,

    Eric Hackett 

  • Thank you Eric.

  • If I have one processor as the SPI master, and the TCAN4551 as the slave, do I need to raise the CS line after each transaction? 

    Can I lower the CS line before the first ever transaction, and then leave it low forever?

    Does this behaviour require a different clock polarity? e.g. if the internal clock works on the very first lowering of the CS, but I don't lower it around each transaction, will there be a problem for the device receiving data?

    Hi Ed,

    The short answer to your question is Yes, you must raise the CS Line at the end of every SPI transaction or this will generate a "SPI Error" and the SPIERR bit will be set in the interrupt register.

    You can not leave the CS pin low forever because the device will not know when the end of the first SPI transaction is, and the when the beginning of the next transaction starts which will result in an error.

    There are two main reasons for this which I will explain.

    1.) As a form of error checking, the TCAN4551 will count the number of SPI Clock Pulses between the CS pin transitioning LOW and back HIGH.  If the number of clock edges is not an exact multiple of 32 (or 1 Word of data) then it will assume there has been an error and either bits were lost (too few clock cycles), or there was noise creating additional samples for bits that didn't really exist (too many clock cycles).  The device will then set the SPIERR flag in the interrupt register so that the MCU will know there was a problem with the last SPI transaction and it will also discard the data for this transaction if it was a "write" (0x61) transaction.

    Because each device register and MRAM data offset address contains 32 bits of data, and the initial Op-Code, Address, and Data Length sent is 32 bits, a single register R/W transaction will contain 2 words or 64-bits of data (or SPI clock cycles).  However, multiple registers or MRAM memory words can be read in a single transaction allowing for any multiple of 32 bits to be read (64, 96, 128, 160, etc.).  Reading and writing multiple registers and words of data at a time reduces the overhead on the SPI bus by eliminating the Address words to be sent for each location and improves overall efficiency. Without the CS pin going High, the device will not know when this transaction is complete.

    2.) The second reason is that the device will return the Global Fault Flags on the SDO pin immediately after the CS pin transitions Low.  This allows the MCU to immediately know if a fault has occurred on EVERY SPI transaction without needing to specifically poll the Status and Interrupt registers.  Included in this is the SPI Error flag which will allow the MCU to know immediately if the previous SPI transaction needs to be repeated.

    If the CS Pin never transitioned High at the end of the previous SPI transaction, it could not then transition Low again at the beginning of the next and it could not provide an updated status of the Fault Flags to the MCU.

    I know it is common to keep the CS pin low for other devices when there is only a single device on the SPI bus, but those devices usually have a fixed number of bits for a SPI transaction, and they don't have the advanced features of returning status data at the beginning of every SPI transaction and counting the number of clock cycles to check for errors.

    Regards,

    Jonathan

  • Great. thank you very much for the explanation Jonathan.