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.

TRF7960 SPI with SS Timing Specs

Other Parts Discussed in Thread: TRF7960

Does anyone know what the timing specifications are for the TRF7960's SPI interface when using SS?  

  • Minimum time between assertion of SS to first rising clock edge?
  • Max SPI clock frequency?
  • Minimum time SS needs to be deasserted between back-to-back SPI communications?

Also, in the case of transmitting 15 bytes using SPI mode with SS, you'd load the first 12 bytes into the FIFO and then you have to wait for more room to become available (which you can monitor via the IRQ and FIFO status registers).  Do you deassert the SS pin after those 12 bytes have been sent and then perform another continuous write to the FIFO address when the FIFO has room for the last 3 bytes, or do you keep SS pin low while you wait, and just transmit the last three bytes?

Thanks,

Ryan Frazier

  • Ryan -

    1. Tste, lead is typically 200nSec, see page 9 here ==> www.ti.com/.../trf7960a.pdf
    2. Max SPI clock...we recommend typical at 2MHz and we don't recommend going above 10MHz.
    3. i don't know that this question has ever come up - will look into it.

    4. you would use the string format 0x8F 0x91 0x3D 0x00 0xF0 + twelve of the 15 bytes to send, and send them (raising SS to get them to go out)...then handle the TX IRQ (i think it will be 0xA0) and send the last three bytes as you describe, then get TX IRQ (which will be 0x80) - I will also look for an LSA capture of doing this with the -60, too.
  • Hi Josh,

    Thanks for the reply.  

    A quick follow up question: When you say "send the last three bytes" I take it that is just a continuous SPI write to the FIFO address (data string: 0x1F + <3 bytes of data>)?  We don't need to go through the whole Reset-Transmit-TX_bytes-Data operation again because that would screw up what the chip is currently sending, correct?

    Also, what triggers the "FIFO overflow error" flag in the FIFO status register?  The datasheet only states "Too much data was written to the FIFO" and "the FIFO was loaded too soon".  The last statement is a little cryptic... Are there other ways the overflow flag can get set or does it only happen when you try and write more than 12 bytes into the FIFO?

    Thanks,

    Ryan