SPI Fram interface timing

[dpaul]

I'm sure this has been dealt with before, but here's a SPI question.  I'm working interfacing an MCF51AC micro to a Ramtron FRAM.  The fram requires multi-byte commands separated by a de-activated /CS.  You can tell when a tx byte has cleared the tx buffer, but how do you know when the byte has cleared the shift register and the /CS line has gone inactive?  It is only then when the fram will properly accept the next command sequence.  At this point, it looks like one must just wait an fixed delay for the SPI subsystem to finish.  I'm not keen to writing such software timing loop dependent code.  Is there any other way to know an SPI tx is truly done?  Thanks for any thoughts!

[kef2]

MCF51AC reference manual: "SPRF is set at the completion of an SPI transfer...". Perhaps SPI Read Buffer Full Flag name is bit misleading, but transfer completes at exactly the same time for both, SPI Rx and SPI Tx.

[dpaul]

Ed:

Thanks for your observation regarding watching the SFRF bit (that's Receive buffer Full).  I've empirically determined if I hang around long enough that the disposable byte clocked back during a byte Tx makes its way through the Rx shifter and into the receive buffer (that is with no subsequent bytes loaded into the Tx buffer), the SPI machinery will by then have set the Chip Select inactive (high). 

That's an indirect and peculiar way to determine the SPI is done, but will work.  That technique also makes it very tempting to leave the SPI transfers (at least for now) in-line code rather than interrupt driven.

Anyway, as I have noted in the past, if this job was easy, somebody making a whole bunch more than I would be doing it!

[TomE]

> very tempting to leave the SPI transfers (at least for now) in-line code rather than interrupt driven.

Especially if the FRAMs you're using can run at 20-40MHz. The CPU SPI maximum speed is 12MHz. You'd be hard pressed to get the CPU to respond to interrupts at that rate, so you might as well wait.

> The fram requires multi-byte commands separated by a de-activated /CS.

I initially read that as "multiple bytes, each separated by a de-activated /CS", but after reading some Cypress FRAM data sheets and their AN304 I take it you meant multi-byte commands with CS continuously asserted, but then the separate commands having CS deasserted between them. I think it will be more difficult to guarantee that CS remains asserted between bytes than making sure it deasserts between commands. If anything interrupts the SPI transfer you may get SS dropping in the middle of a command. I'd suggest programming SS as GPIO (RGPIO if using the 8-bit SPI) and control it manually. If you're using the 16-bit SPI with the FIFO then you may be able to guarantee "continuous multi-bytes" by keeping the FIFO full, but during a long read or write sequence your code may still get interrupted for long enough to drop out. Another advantage of using RGPIO to drive SS is that you'll be able to single-step and breakpoint your code.

Tom