UC3B : SPI(slave) TXEMPTY isnt get set

Last post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I configured UC3B064 in SPI slave mode (8 bits)

I write TDR:TD (data register)
I see that TXEMPTY becomes 0
and TDRE (transmit data register empty) is 0
so far so good

then read SPI from master
at this point
TDRE is 1 (empty)
but TXEMPTY is still 0 (non empty)

even if I read over SPI few more times (I did verify with scope that data is being actually read)

Why doesn't my TXEMPTY changes to "empty"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TXEMPTY makes sense in master-mode because transmission is buffered and it is usefull to know when the bus is idle.

The datasheet only refers to TDRE in slave-mode., so why not use that if you really need to know when end-of-slave-transmit occurs ?

Actually.., why are you worrying about when the transmit completes on the slave ?,
You should be using RDRF to trigger your code which may (or may not) then put something into the TDR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I signal the presence of data in the slave by using a GPIO pin. Suppose I have following sequence occur
1. slave has two bytes to report
2. slave asserts the RTS (ready to transmit) pin (GPIO)
3. slave loads data into data register, TDRE goes high then goes immediately low since data falls through into the shift register (TXEMPTY = 0, TDRE = 1)
4. slave pushes next byte to data register (TXEMPTY = 0, TDRE = 0).
5. master reads data, buffered byte falls into the shift register. TXEMPTY = 0, TDRE = 1.

If I use TDRE to deassert the RTS, it is possible that master will detect RTS going down _before_ reading second byte.

And that's why I would prefer TXEMPTY.

On the other hand, in slave mode, before transmission TXEMPTY starts at 1, but it never goes back to 1 after transmission. I would understand if in slave mode TXEMPTY would just be fixed at one value all the time. But I don't understand why it would change one way, but not back.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only things I can think of are ;
- deassert RTS after a time-delay after the last byte has been loaded into TDR,
- have the master assert a GPIO (CTS) to the slave to indicate it has received the last byte,
- always send a fixed-number of bytes and have the master ignore subsequent RTS transitions until all those bytes are received.