AnsweredAssumed Answered

ADuC706x SPI slave -- tx fifo problem

Question asked by m.teichgraeber on May 28, 2014
Latest reply on Feb 17, 2016 by MMA

Hi,

after having used an ADuC7060 as an SPI master in the past, I'm trying to use this controller at 10.24MHz as an SPI slave now. The master, an LPC, is using an SCLK of 2MHz (for testing purposes, a lower rate will be used in production) with CPOL and CPHA both set to 1.

I've set the following flags in the slave's SPICON register:

     SPIEN | SPICONT | SPIZEN | SPIOEN | SPICPO | SPICPH

 

What I'm trying to achieve is to read byte streams of up to 20 characters containing measurement data out of the ADuC7060 SPI slave. For now I'm using a fixed byte buffer with the contents "Hello world.\003". The master sends zeros until it reads an ETX character (ASCII 3).

I'm filling the TX fifo with the byte pattern 1, 2, 1, 2, prior to an /SS assertion. The interrupts are served by an FIQ handler that, for now, isn't left until /SS is not asserted anymore. The handler continuously reads SPISTA, reads out SPIRX, and writes bytes to SPITX as SPITXFSTA permits. 

 

What I would expect is to receive the whole byte stream, perhaps with some zero bytes in between (SPIZEN=1), since the ADuC7060 won't be able to fill the tx fifo fast enough. What I'm getting instead is a byte stream with some of the original bytes lost (sometimes more, sometimes less; below, the "Hello world." still can be recognized):

 

    1 2 1 2 0 0 0 'e' 0 0 'l' 'l' 'o' ' ' 0 0 0 'r' 0 0 'l' 'd' '.' 0 ETX

                           ^TXUF          ^TXUF          ^TXUF            ^TXUF

 

During this sequence, SPISTA is read six times. A TX underflow is reported in all but the first STA values. No SPIFOF is reported.

What I'm wondering about is, why a byte written into TXBUF under the condition that SPITXFSTA is < 4 -- i.e. the fifo isn't full -- would not be visible on the MISO line. It appears to me that if an tx underflow occurs (SPITXUF=1), one should expect that one or more new bytes written into SPITX get lost. Is SPITXUF an error condition one can not easily recover from?

What could be wrong with my setup, apart from that the handler is to slow? I've attached the source file of my spi slave module for reference.

 

Perhaps it's best not to request more than 4 bytes in one SPI sequence, and to make sure that these bytes are already present in the TXFIFO when /SS is asserted.

 

I'm also not sure about the SPICONT flag. In the example SPI slave programs it is usually set, and one user reported that he had to activate it to get his SPI slave working (http://ez.analog.com/thread/8995). But it appears to me that an SPI slave works the same, regardless of whether SPICONT is set or not. The data sheet says what it does in master mode. Is it applicable for slave mode too?

 

Kind regards,

Michael Teichgräber

Attachments

Outcomes