UART0 Output Data Loss at 115200 bps (ESP_LOG Corruption) (IDFGH-16037)

[italocjs]

Answers checklist.

• [x] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [x] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [x] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Problem Statement

When using UART0 (GPIO1/GPIO3) for output on ESP-IDF, printed data intermittently loses segments of output. This occurs at 115200 bps, regardless of whether the UART driver is explicitly started for port 0 or if default IDF printing is used (i.e., no driver start for printing).

Example Output

• Expected: I (1293) testTag: 123465789ABCDEF123465789ABCDEF123465789ABCDEF
• Actual: I (1293) testTag: 123465789ABCDEF123465789123465789ABCDEF

I also print data as json using printf, example:

• Expected: { "timestamp": 1293, "tag": "testTag", "data": "123465789ABCDEF123465789ABCDEF123465789ABCDEF" }

• Actual: ` { "timestamp": 1293, "t: "testTag", "data":BCDEF123465789ABCDEF123465789ABCDEF" }

No other peripherals are enabled, only main task exists.

Missing segments appear consistently in the output stream, using both printf and ESP_LOGx. This behavior is not new to IDF5, i also seen this on IDF4.4

Scope of the Issue

• Reproducible across 20+ development modules (mix of CH340 and CP2102 USB-UART bridges) and proprietary boards (original CH340, sourced reliably).
• Issue does not occur on UART1 or UART2 (any pins other than GPIO1/GPIO3).
• Multiple USB cables tested, same behavior.
• Issue is intermittent.
• Tested on both Windows and Linux, issue is consistent.

Additional Observations

• Flashing the board over UART0 at 921000 bps works flawlessly every time.
• However, ESP_LOG output at 115200 bps is consistently corrupted/missing segments.
• Power is STABLE, monitored via oscilloscope to be sure. both the ESP32 and CH340 have decoupling capacitors and a reliable power source.

Request for Suggestions

I find it odd that flashing at much higher speeds (921000) works reliably, but printing/logging is corrupted at a lower baud rate. Any suggestions on how to further diagnose or resolve this issue? At the same time i don't think is a software issue as surely others would notice, but i'm not sure what in hardware could be causing this, as both common esp32 dev modules and proprietary boards have the same behavior.

---

If additional logs or test scenarios are needed, please let me know.

[ginkgm]

Hi @italocjs ,

Thanks for the report.

Have you tried latest IDF master to see if the issue exists? Maybe it's known issue that we have resolved so far.

And could ou provide a piece of code to reproduce the issue? (with the exact IDF commit sha that can reproduce the issue)

[agzzzz]

I am having log corruption with a project and was able to create a minimal example to reproduce. It only occurs when performing ADC conversions, so it might be different than the problem of @italocjs.

The test prints a fixed string on app_main using ESP_LOGI while task t_read_adc performs ADC conversions with adc_oneshot_read. I used the default sdkconfig generated by the IDF, without any changes. Configuration was only changed when testing on another UART port.

These are my observations about the issue:

1. Log corruption only happens with ESP32 (did not happen with ESP32-S3 or ESP32-C3)
2. The source of the problem was a burst of sequential ADC oneshot readings without a delay between them
3. Log corruption does not happen if you change the UART port used for logging (eg. UART1)
4. I can only reproduce in a simple example by setting the ADC read task affinity to core 1
5. In a more complex project, the problem occurs even with no affinity or affinity to core 0
6. Varying the length of the printed log affects the result (longer logs are more susceptible)
7. Tested on v5.5 (8c750b088c7cd857d079c0eeb495da199b359461) and v5.4.2 (f5c3654a1c2d2a01f7f67def7a0dc48e691f63c0)

Snippet of corrupted output log:

I (10097) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (10297) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (10497) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (10697) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (10897) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (11097) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI (11297) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (11497) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (11697) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (11897) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (12097) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (12297) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Snippet of expected log:

I (5797) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (6357) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (6917) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (7477) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (8037) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (8597) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (9157) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
I (9717) app_main: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Repository with project to reproduce

[italocjs]

Hello, It seems its indeed related to using ADC My code is using wifi, nimble and adc1 to read the psu voltage. i have tried several things to mitigate but failed so far.

• changing baud speed
• changing uart adapter
• double checked grounding and power.
• increasing/decreasing buffer for uart
• using flush.

The data becomes sligtly corrupted anyways. For reading is bad but liveable, problem is that i have an jig that flashes and run tests in the board, it is not tolerant to missing characters, and this is causing me a big headache.

Below is an example of what i consider "corrupted", notice the missing data in the timestamp.

I (15:12:49.737) BatteryHealth: {'time': 35998, 'voltage': 13.855, 'state': 'OFF', 'marker': ''} I (15::49.747) BatteryHealth: {'time': 36098, 'voltage': 12.410, 'state': 'OFF', 'marker': ''},

I have tested this on IDF 4.4.7 and 5.5.1, same behavior. Unfortunately this product absolutely needs ADC reading. any ideas on a workaround?

[kurozz]

@italocjs As a workaround, try using another UART, such as UART1, for log output. You should be able to set it to the same pins, but may have some corruption during the change of UART ports.

You can also avoid using oneshot ADC and use continuous ADC instead.

[italocjs]

Hello! Thanks for the suggestion, Previously i was sampling 100 adc reads (no delay) and averaging to minimize noise, just removing this step fixed the issue. if i only take one sample, all works fine (although i suffer from more noise). I take a sample every 100ms (battery voltage)

I am already using UART1 (for GPS) and UART2 (for sattelite dish), but i will try temporarialy disabling one of them to test how it goes. i'll also try continuous adc and report back here.

[therealergo]

I'm also seeing this issue. I have an existing well-tested firmware built using ESP-IDF 5.1.6 that does not experience this problem, and porting it to 5.5.1 causes it to occur. Changing the peripheral block used for printing (UART0/UART1) does not resolve it. The product takes 8x averaged readings to measure battery voltage & temperature, and we use the UART to communicate with a test jig so the UART needs to be functional. Adding delays between the readings significantly reduces the occurrence of this issue, but does not completely eliminate it.

[ginkgm]

Hi @italocjs , @agzzzz , @kurozz , @therealergo ,

I tried with @agzzzz 's test (thanks for detailed reproducing steps), with one only modification - change ADC task Affinity to Core 1, but can't reproduce the issue on my side.

My hardware configuration are 3 official ESP32(-no-suffix) boards - WROVER-KIT with WROVER and WROVER-E modules, and DevKITC-M with Wrover-E modules. I have nothing connected externally.

It looks very likely a hardware issue to me. What's your source connected to the ADC pins, and how's the connection between ESP32 and the ADC source/UART transceiver. Are the routes on PCB or jumping wires?

If you are using official boards as me, please provide more detailed hardware description so that I can try to reproduce the issue again. Or I'm afraid that we can't confirm it's software issue or not and fix the issue efficiently online, if the issue can't be reproduced on our side.

[italocjs]

Hello @ginkgm, thanks for trying it out!.

I can reproduce the same behavior on devkits and on my boards , being powered externally or by usb. and it happens across idf versions (tried 4.4.4, 4.4.7 and 5.5.1)

The exact chips I used to test were:

• ESP32-WROOM32E-N16 (sourced from https://www.lcsc.com/product-detail/C701343.html and assembled by JLCPCB)
• ESP32-WROOM32E (commonly found usb devkit)

Both had shown the same symptoms when using multisampling (100 every 100ms). I have reduced it to a single shot every 100ms and no more corrupted data. the readings are a bit more noisy as expected but using a code filter helps.

The product I made is powered by an XL1509-3.3 (3v3 step-down buck), output is very stable and following design recommendation (using 220uF electrolytic on output + 100nf decoupling near chips)

I do not have any WROVER chips to test, but since you mention it does not happen on it, I'll buy one and try it too. maybe its something related to the actual chip and that could help us investigate it further.

[ginkgm]

Thanks, let me try again..

[agzzzz]

Hello @ginkgm, thank you for reviewing this problem.

I do not have an official board with the ESP32-WROOM to test with. My tests were with a generic development board and one of our products. I do have an ESP32_LyraT board (v4.3, ESP32-WROVER-E).

The problem also occurs with the LyraT, using ESP-IDF v5.4.3. You do have to change the core affinity to 1, as my test code defaults to core 0, but you said that was done. Unfortunately, I do not know what else could be affecting the test.