• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2016 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5529 DMA hangs in UART Rx

RAHUL TT
Expert 1766 points
Other Parts Discussed in Thread: CC1101, SIMPLICITI, MSP430F5529

Hi,

We are working on MSP430F5529 board with CC1101 radio module using SimpliciTI stack to simulate multiple end device and an access point. The access point sends the received packets from ED to another application via UART and the response from the application is sends back to End device.
Earlier we were using UART interrupts for TX and RX and when the wireless data rate is high we missed many serial bytes. This might be due to entering in the critical state (disables interrupt) by the simpliciTI stack. So we implemented DMA in UART TX (polling) and RX (fixed byte interrupt).
We tried a simple DMA UART TX and RX example and it is working fine. When it comes with simpliciTI stack RX is hanging after some time and no further RX DMA channel is triggered, but TX is working fine. A somewhat similar issue was noticed here http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/222669.aspx .
This seems to depend on number of end devices,if a smaller number of end devices are used it works for a long time before hanging. Since the example code is working properly, I wonder if there is something in the SimpliciTI stack that prevents the working of DMA after a while?
Please let us know your thoughts about this.

Thanks
Rahul
  • 0
    Guru 227245 points

    RAHUL TT said:
    A somewhat similar issue was noticed here

    No, this one is about the DMA9 erratum which is related to the eUSCI module. You don't have an eUSCI module.

    However, it might be your DMA code that has some racing condition. DMA is edge triggered. When you reconfigure DMA for the next data block or something like that, and an RX event happens before the DMA is armed again, then it will miss this trigger. And since no DMA happens to read RXBUF and clear RXIFG, no more RX triggers will come.

  • 0 in reply to Jens-Michael Gross
    Expert 1766 points

    Hi,

    Thank you very much for your response. As you said, it seems like the DMA RX code has racing condition. The RXIFG flag remains set after the DMA hangs.  I think this racing condition does not occur in our DMA UART TX code since data transfer occurs only after the completion of previous transfer.

    But in case of DMA UART RX, bytes are received continuously from the application at a high rate. When the Wireless data rate is high, RF receive ISR and entering critical sections will be more which leads to a delay in handling DMA ISR where we are reconfiguring the DMA for the next data block.

    Please let me know by what changes should I make to avoid this racing condition?

    Thanks

    Rahul

  • 0 in reply to RAHUL TT
    Guru 227245 points

    You could run the DMA in repeated mode. So the interrupt will tell you that the buffer was full, but DMA will seamlessly continue to fill the buffer from start with new incoming data.
    Of course this may rise other problems, but at least you won't have the DMA stopped whiel data arrives, and then stalled.

    Another possible way would be to check whether RXIFG is set when you have just readied the DMA. If it is, then the DMA has missed a byte, and you can manually clear and re-set the RXIFG flag, to trigger the DMA and get it back into the gear.

  • 0 in reply to Jens-Michael Gross
    Expert 1766 points

    Hi,

    Thank you for your response.

    Jens-Michael Gross said:
    Another possible way would be to check whether RXIFG is set when you have just readied the DMA. If it is, then the DMA has missed a byte, and you can manually clear and re-set the RXIFG flag, to trigger the DMA and get it back into the gear.

    Since we cannot confirm that only 1 byte is missed by DMA and every byte is critical in our application. We prefer to go with the 1st option.

    Jens-Michael Gross said:
    You could run the DMA in repeated mode. So the interrupt will tell you that the buffer was full, but DMA will seamlessly continue to fill the buffer from start with new incoming data.

    Thanks

**Attention** This is a public forum