Flushing UART with full buffer prevents further reads from buffer (IDFGH-6819)

[gril002]

Environment

• Development Kit: none
• Kit version N/A
• Module or chip used: ESP32-WROOM-32D
• IDF version: v4.4
• Build System: idf.py
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // 1.22.0-80-g6c4433a
• Operating System: Windows
• environment type: PowerShell
• Using an IDE?: Yes, VS Code with Espressif IDF extension
• Power Supply: external 3.3V

Problem Description

When calling uart_flush() with a full UART RX buffer, the ring buffer is cleared, but all subsequent calls to uart_read_bytes() return zero bytes. I have tracked the problem down to "xSemaphoreTake(rbGET_RX_SEM_HANDLE(pxRingbuffer), xTicksRemaining)" returning pdFALSE in ringbuf.c at line 776 and subsequently not actually reading any data. This essentially means, that once you call uart_flush() with a full RX buffer, you can no longer read any UART data until you reboot the device. If the buffer is not full, when flushing, everything functions as expected.

Expected Behavior

calling uart_flush() with a full UART RX buffer, clears the ring buffer and subsequent calls to uart_read_bytes() return data received after flushing.

Actual Behavior

calling uart_flush() with a full UART RX buffer, clears the ring buffer but subsequent calls to uart_read_bytes() return 0 bytes.

Steps to reproduce

1. Load the uart_echo example from the release/v4.4 branch
2. Configure pins etc. in menuconfig
3. Paste code below into uart_echo_example_main.c
4. Compile and upload to ESP
5. Launch JTAG debugger
6. Send enough data to fill UART buffer
7. Set a break point at "if (change_me == true)"
8. change the value of change_me to true
9. Follow code execution

Code to reproduce this issue

GIST

Debug Logs

Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is *too* long.

Other items if possible

• sdkconfig file (attach the sdkconfig file from your project folder)
• elf file in the build folder (note this may contain all the code details and symbols of your project.)
• coredump (This provides stacks of tasks.)

files.zip

[negativekelvin]

708e3b6

[gril002]

That definitely looks like the solution. I'll test it tomorrow. Thanks! Just curious, any reason this was not included for v4.4 launch? Also, would you recommend switching my (still in development) project to the master branch or just manually port this patch to v4.4?

[Alvin1Zhang]

Thanks for reporting and the notes. We have back ported the fix to release/4.4, currently under internal reviewing. Will sync up once the fix on release/4.4 is available.

[gril002]

I have manually applied the commit changes to my uart.c and can confirm, that the problem is resolved. As far as I am concerned this issue can be closed, unless @o-marshmallow wants to do anything else.

[o-marshmallow]

Hi @gril002 , thanks for confirming it works.
Personally, I would advise you to stay on release/v4.4 branch as master is slowly making its way to the next major version.
Any bug found on master and v4.4 will be fixed to master and then backported to v4.4. This current fix is currently under (internal) review, it will soon be merged to release/v4.4 branch.

[Hallot]

Is it also present in release/v4.3, would it be possible to backport it there as well please?

[AxelLin]

Is it also present in release/v4.3, would it be possible to backport it there as well please?

The fix is already in v4.3 branch: a5a4718

[Hallot]

Brillant, thank you.

[JBKingdon]

Hi, I ran into this problem recently using platformIO which is currently on idf 3.5.0. Is there any interest on back-porting the fix to the 3.x stream or is this a problem better taken up with the platformIO project?
Sorry for the confusion - I completely misunderstood the versioning. platformIO is currently on 4.3.2 of IDF and will doubtless pick up the fix in due course.

[ndjur]

I'm sorry, I'm having the same issue that has been described here, but I'm not sure if I understand what needs to be done to resolve it.
I'm using IDF 4.3.1 and I would prefer not to change it as things are running smooth (except for this one), and I remember that it was not an easy process to update the version that I was running before getting 4.3.1.
So, should I just take the new uart.c and put it ...\components\driver folder, and where to take it from?
Thanks a lot.