[TW#16347] Calling uart_flush(2) corrupts data thereafter (IDFGH-3370) #1202
Comments
|
I had reported this issues a while back on the forums and didn't get any response for it I didn't get a solution for this so far. I have written a flush function myself just to read the remaining data from the buffer as a temporary fix. |
|
Thanks for the link.
That response to your observation makes me think I should provide a simple piece of code showing that calling uart_flush(1) affects uart2. Maybe that might attract some interest in this issue? |
|
Sorry - reopening - I closed this by mistake. |
|
This problem seems related to esp-idf/components/driver/uart.c Line 1012 in 80eb3b6 Does not occur when commented out. Also do we want to reset both tx & rx fifo in flush? |
|
@negativekelvin wrote: Yes, after calling uart_reset_fifo(), the ring buffer seems "out of sync" with any new incoming characters. So maybe something is missing in the above ring buffer code? It does seem reasonable to have individual control over rx and tx flush. Maybe uart_tx_flush() and uart_rx_flush()? For backwards compatibility uart_flush() could call both. |
|
It doesn't seem to be related to ringbuf but to the FIFO and FIFO reset is a hardware function |
|
If we simply empty the FIFO by reading out the bytes instead of resetting it, it seems to work |
|
Interesting. As a side note, in my actual situation (not this test loop), the rx fifo has overflowed and I want to recover from the fifo overflow condition. So I was hoping the flush would empty all rx data and reset the hardware including it's overflow flag so that I could recover without having to issue a hard system reset. |
|
I know, I changed the test by putting the flush between write and read. That is how fifo overflow is handled by ISR: esp-idf/components/driver/uart.c Lines 696 to 702 in 80eb3b6 |
|
Emptying the fifo might be a good solution. I don't know if that would clear an overflow condition or not. I'm not sure how to force a fifo overflow for this simple test environment. However, in my actual application program I'm polling another device. If I set a breakpoint right after the poll message goes completely out, the system stops at the breakpoint and then the other device responds with more than 128 characters. At that point since irq's and the ring buffer are stopped (by my breakpoint), the hardware fifo overflows. So I'm looking for a way to recover from situations where the fifo has overflowed. One obvious solution would be to use hardware flow control, but that isn't an option due to the limited pin count. |
|
@costaud any thoughts? |
|
@igrr Thoughts? |
|
Yes, this is caused by a hardware issue with FIFO reset. The software fix is in review now and should be merged soon. |
FayeY
changed the title
Reported from github: #1219 #1202 After providing a simple code to digital team, they confirmed that this is a hardware bug. Root cause: The fifo reset signal is incorrectly connected If we want to reset tx fifo of UART2, we have to set txfifo_rst bit of both UART1 and UART2 If we want to reset rx fifo of UART2, we have to set rxfifo_rst bit of both UART1 and UART2 Workaround: we don't use fifo rst bit in driver. Documentation: Digital team would update TRM and give more explanation about this issue.
|
@igrr does this hardware bug apply to the TX fifo as well? I'm getting old data coming out of the TX pin on UART2 after a software reset, but after changing to UART1 everything works fine. Full power cycle fixes the problem once (until software reset, then it's back to normal). There doesn't seem to be any workaround code for clearing the TX fifo, it's just toggling the reset bit. |
github-actions
bot
changed the title
|
Hi, @jeremyherbert |
|
quite recent: v4.2-dev-1575-ga3520970f with xtensa-esp32-elf-gcc (crosstool-NG esp-2020r1) 8.2.0 Is there some hack I can put in place in the meantime? This one is a bit of a showstopper for me. |
|
Change this line in and remove this line in |
|
That works for me; now my issue is gone with UART2. Thank you! |
Description:
Calling uart_flush(2) seems to corrupt the fifo or ring data.
It seems that once corrupted, a hard reset is the only fix.
Steps to reproduce:
I am using the latest esp-idf master 4048db3.
Connect TX2 to RX2 with a jumper wire.
Run the provided code.
The sample code will reproduce the issue reliably within a few seconds.
All received data from UART2 after the loop “count == 5” is then corrupted.
The sample code performs the following basic logic:
The board that I am using a esp-wroom-32 dev kit, but I doubt that it is board dependent.
Code to Reproduce
Captured Log
The text was updated successfully, but these errors were encountered: