Problem solved. My assumption was that the last value written to the TX FIFO would be the value stuck on the bus if I stopped feeding the FIFO. The TRM (24.3.3.2.2) explicitly says this:
"When the FIFO is enabled, the data read while the underflow flag is set will not be the last word written to the FIFO." I assume that "data read" refers to data read by the master. And I never did figure out what the byte stuck on the bus corresponded to, seems fairly arbitrary. Anyway, the solution is: If using the TX FIFO, you must keep it serviced. If you want to implement a lazy man's transmitter, that is, only write to the transmitter when you actually have something to send, then don't use FIFO mode. In this mode it works more like other SPI devices - the byte repeated on the bus will be the last byte written to the TX register. Thanks, Jim On Sunday, August 25, 2013 5:09:32 PM UTC-4, shedmeister wrote: > > I'm having an intermittent problem running the BBB's SPI1 in slave mode. > I have designed all my TX messages to end in 0, and have verified every > way I know how that the last byte written to MCSPI_TX0 is 0. But after a > few minutes of running, there is a non-zero value stuck on the output. It > is usually 0x80, (I am in 8-bit mode), and I can clearly see the 0x80 > coming out of the D1 line on a scope. The communication is very reliable > initially, several messages get through OK before the error. I have to > soft reset the BBB'S SPI to clear the error condition. > > Any ideas? > Thanks, > Jim > > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
