• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 591 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.

Original question:

AM2634-Q1: UART LSR register exception: RX_FIFO_STS field equals 1 while RX_FIFO_E field equals 0

AM2634-Q1: Software-Reset UART will only reset the RX FIFO pointer but not flush the RX FIFO contents?

Will Gao
Intellectual 2335 points
Part Number: AM2634-Q1

Hi BU, 

Customer requests me to give the root cause for an early issue of UART controller: E2E thread. 

The early issue can be summarized as: the UART controller can't remove the RX_FIFO_STS flag by trying to read out the RX FIFO contents. This issue can only be recovered by using MSS_RCM register to hardware reset the UART instance and then re-init the UART instance. 

And the issue is happened when SBL jumping to APP. And I found that in UART_Open API, the driver will software-reset the module by calling UART_moduleReset API. If during the jumping process, the UART controller receives some frame, and there is possible that one frame is with error. Then after software-reset the UART instance, the FIFO reading pointer will back to the start. So the software can't flush the FIFO contents anymore, and that means the error frame can't be read out. So the RX_FIFO_STS flag will be never cleared. 

And hardware-reset the UART instance will clear the FIFO contents, so that the RX_FIFO_STS flag will not be set anymore. 

I want to double confirm with you the above behavior (Software-Reset UART will only reset the RX FIFO pointer but not flush the RX FIFO contents. Hardware-reset will clear the contents), if it is true, I think it will be the root cause for this issue, and so that close this problem in my customer side. Please check it. Thanks. 

Regards, 

Will