• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 988 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5510 DMA UART TX buffer size? DMA ISR fires when bytes are underway?

Hendrik van den Boogaard
Prodigy 220 points
Other Parts Discussed in Thread: MSP430F5510

I am using the MSP430F5510 to transfer a block of bytes out on the UART (USCI_A1). This works as expected. But: the MSP is hooked up to an infrared transceiver that has the nasty behaviour of immediately echoing back all bits that are sent to it.

Therefore I disable the RX interrupt upon initiating the DMA transfer and I enable the DMA interrupt. I expect the DMA interrupt to fire when the transfer is 'done' so I then enable the UART RX interrupt again. This way I expect no echoed bytes triggering the RX interrupt. Or at least; I expect only the LAST sent byte to possible triggering the RX interrupt, because the TX buffer can only hold one byte. The software is capable of detecting this last byte.

But what I see is the last 3 bytes (of a packet of 9 bytes) actually triggering the RX interrupt as soon as this is enabled in the DMA ISR.  So I see the last 3 of the 9 bytes echoed back in my RX routine. How is this possible? It seems that the DMA ISR fires prematurely? Or that there somehow is some more buffering going on?! The IRDA transceiver does not do such a thing, it (more or less) immediately echoes back, and definitely does not delay a complete byte or so.

Edit: What I can check tomorrow is invert a pin of the MSP430 in the DMA ISR and see when this happens compared to the output bits on the UART TX...

  • 0
    Guru 23000 points

    Looking to the USCI block diagram, I could image; The USCI initiates a DMA trigger at the moment it has moved the data from the tx-buffer to the shift register, the DMA will place a new byte into the tx-buffer, when this is the last byte for the DMA to transfer it will trigger an interrupt, at this point the transmitter holds 2-bytes to send, but the receiver buffer also holds one byte, when the DMA interrupt enables now the receiver interrupt you get 3-bytes.

  • 0 in reply to Leo Bosch
    Prodigy 220 points

    Ah, that makes sense. The 3rd byte being in the RX buffer. It's late now so I will continue on this tomorrow. But what should be the best way to work around this? Add an interrupt for TX so that I will only enable RX when TX is done? Or take the uncertainty of timing and DMA out of the equation and just go for an interrupt driven TX routine for the whole packet so I can keep track of each byte that is actually sent?

  • 0 in reply to Hendrik van den Boogaard
    Guru 23000 points

    Hendrik van den Boogaard said:
    It's late now

    I think we are in the same Amsterdam time zone.

    Using DMA ; On DMA interrupt, read Rx buffer and so clearing IF (one Rx byte less), clear/preset a counter to flush the next 2 bytes and enable Rx interrupts. I would also add a timer for ~1.5 (or ~2.5 depends on how you do it) byte, when for whatever reason you don’t get the 2 bytes you get a timeout and can reset Rx to the normal state.

    Only with Tx interrupt; Set a bit to flush the next Rx, and I would also add the timeout.

  • 0 in reply to Leo Bosch
    Prodigy 220 points

    Leo, thanks for your answer. The 3rd byte is indeed in the RX buffer (as it always is).

    In the DMA ISR I now dummy read the UCA1RX register to clear the IFG, and I set a boolean that I must screen incoming bytes. From that moment there will only be 2 bytes left. Because the protocol has a defined start-byte and end-byte, I can check if, when I expect the end-byte, I actually receive the end byte or something else. As soon as I do, it means the transmission is over and I can restart the state machine to look for the start-byte again.

    If for any reason the first of the two bytes, being a generic data byte, contains the same value as an end-byte, then I would start looking one byte too soon, but that does not matter because the byte coming next is not a start-byte but the actual end-byte.

    Problem solved. Thanks for your help.

  • 0 in reply to Hendrik van den Boogaard
    Guru 23000 points

    You’re welcome. Till maybe next problem!

**Attention** This is a public forum