UART0 Slow Baud Reset Issue on Arduino ESP32 | Update : Suggests reset issue while writing Core register dump for CPU 1 at UART0 Baud < 6207 #7092
Comments
|
@gracengeer - It all sounds a bit confusing... I see this error: And also this example code: Both seem linked to each other... Which has nothing to do with the Serial port or its baudrate. |
SuGlider
added
Type: Question
|
@SuGlider - Thanks for assigning. I tried to emulate a Divide by Zero error on purpose using the sample code to demonstrate the issue. For references, please try to compare the debug output I have added at 4800 baud set on UART0 vs 9600 baud set on UART0 in code, the Core 0 debug output which is linked to UART0 gets stuck at some point without printing out the complete backtrace for 4800 baud set on UART0. It is at this moment the ESP32 is frozen completely. This problem occurs until the UART0 baud is 6207 and above where ESP32 can reset by itself after getting this exception error. Also to add, WDT reset even doesn't help to recover error/exceptions for lower bauds on UART0 at runtime. |
SuGlider
added
Type: Bug 🐛
|
@gracengeer - Thanks, issue confirmed. Indeed, it seems that ESP32 can't recover in Soft Reset after an Exception when its UART 0 has been set to any baudrate lower than or equal to 4800. It seems to be an issue from IDF, or something else (ROM SW?), and not with Arduino. |
|
@VojtechBartoska - I tested it with 2400, 4800 and 9600. using baudrate 2400 -- system halts after incomplete Guru Mediation Error messageusing baudrate 4800 -- system halts after incomplete Guru Mediation Error messageusing baudrate 9600 -- system resets and restarts after complete Guru Mediation Error message |
|
@SuGlider @VojtechBartoska - I have tried to emulate this using ESP-IDF on IDF versions v4.4.1 and v3.2 earlier to compare with Arduino and it is able to undergo reset without any issue, so definitely doesn't look bad on the ESP-IDF. I wonder if it is coming through there some configuration setting under sdkconfig file for Arduino? Test Case: UART0 set to 4800 baud ############################################################################## Core 0 register dump: ############################################################################## rst:0x7 (TG0WDT_SYS_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) ############################################################################## static const int RX_BUF_SIZE = 1024; void init() } void app_main(void) } |
|
I have tried to check further on this issue. To brief, we currently have thousand of production devices at unmanned remote location which may affect due to this critical bug and unable to resolve unless someone resets it manually so kindly looking for a quick addressal and response to this bug. Like I mentioned earlier it is unable to perform WDT resets but that doesn't seem to be the case actually. Code Logic Case : UART0 @ 4800, with infinite while loop inside void loop() with task WDT timer enabled Output : In one of our production device, I noticed a fatal error with message Instruction Fetch prohibited but seem the ESP32 was able to reset by itself. It was writing Core register dump for CPU Core 0 Code Logic Case: UART0 @ 4800, recurring function call of void loop() In above case too, the device is able to undergo reset on this fatal error. So the next step was to verify a Divide by Zero error in a function running as a task on Core 0 and Core 1 and comparing their debug outputs. Case : Divide by Zero Error code as Task on Core 0 Output: Core 0 register dump: Case : Divide by Zero Error as Task on Core 1 Output: @VojtechBartoska @SuGlider : I wasn't able to simulate the code break instruction, but looking at the debug output of @SuGlider and if you check divide by zero error of mine, both seem to write to the Core 1 register dump and got stuck on low UART0 baud. And with above Divide by zero code that I tried to run on Core 0 and Core 1 with the output it confirms that any exception or fault that is generated on Core 1 when UART0 baud< 6207 seem to freeze ESP32 whereas if on Core 0, it is able to reset. As Arduino sketch runs on Core 1 and possibly there would be many cases leading to such fatal errors, its not very easy to predict on code level and catch runtime behavior of ESP32 and needs to be solved as soon as possible. For me, it is a mission critical application and a very critical bug to be taken care of, so kindly looking for a quick attention. |
gracengeer
changed the title
|
@gracengeer - It is possible to choose the Core where Arduino Task will run using Arduino IDE. Would it solve the issue?
|
|
@gracengeer - I just tested your sketch and you are right! But if I set Arduino to run in Core 0, it goes through the reset and starts over again correctly. It seems that this is the way to solve this issue as a Work Around... |
|
@SuGlider : Unfortunately it is not as straightforward for me to fix this using suggested workaround. Since my current application is pretty much stable on an older version Arduino for ESP32 1.0.4/IDF v3.2.3 which doesn't have the option to set Arduino sketch execution CPU Core. If I happen to update to the newest version Arduino for ESP32, which I tried earlier, it breaks most of my current application with some functions unable to compile totally. Same scenario is if I force the code to be executed on Core 0 using Task for my current older version Arduino. The workaround would also demand a lot of time - investigation effort for me which is not feasible at the moment and wouldn't guarantee the code stability until production run. The issue I have posted are actually identified in production run and not reported over several Arduino revisions until now. Also, until the root cause is fixed, workaround doesn't sound a good solution for complex piece of code, so if possible I would be glad if it is solved at root level. I am willing to contribute in whatever possible manner. |
|
There is a way to change the Arduino Running Core within ESP32 1.0.4/IDF v3.2.3. This file is at The file is at: Open <sdkconfig.h> and search for change it use Core 0: Recompile your sketch and now Arduino will run in Core 0 instead of Core 1. For your information, this is used in extern "C" void app_main()
{
loopTaskWDTEnabled = false;
initArduino();
xTaskCreateUniversal(loopTask, "loopTask", 8192, NULL, 1, &loopTaskHandle, CONFIG_ARDUINO_RUNNING_CORE);
} |
I'll investigate it and try to find more information about it. |
SuGlider
added
the
Status: Needs investigation
Noted, thanks for the information. I was able to find the sdkconfig.h but I wondered if it was pre-compiled static file based on menuconfig settings because it mentioned not to edit anything. For now, my application uses all three UARTs but luckily one UART is using 9600 baud whereas other two are 4800 and 600. I reconfigured the UART0 to use at 9600 baud as a workaround. I will try changing the core as per your suggestion and see if this workaround is also an available option incase for my application. Looking forward to your investigation. |
In continuation to above issue, we tried to use a quick fix to have UART0 with 9600 baud to be able to write the log without any freezing. But it still seems 9600 baud on UART0 also not a fix after we tried to implement a timer0 based WDT reset due to unidentified issues coming in our production code. This could be simulated with the minimal sketch as follows. The freezing seem to happen immediately or after a few successful resets if the timer0 is not cleared while testing this minimal code.//IDF version: v3.2.3-14-gd3e562907
|
|
@gracengeer - I have tested the sketch of the comment here above. Output (I started the Serial Monitor at 115200 and then I changed it to 9600, in order to see the sketch messages): |
Board
ESP32 Dev Module
Device Description
None
Hardware Configuration
None
Version
v2.0.4
IDE Name
Arduino IDE, esp-idf on Visual Studio Code
Operating System
Windows 11
Flash frequency
80MHz
PSRAM enabled
no
Upload speed
921600
Description
ESP32 UART0 freezing and stuck at low baud rate and is unable to recover on WDT reset for exception errors
I am working on an ESP32 application which requires use of all three UARTs at low baud rate with UART0 baud rate strictly needed to be 4800 due to master IC specification.
To summarize, the behavior looks like following,
Arduino version for ESP32 : v1.0.4 with underlying esp-idf : v3.2.3 for Case 1 and Case 2
esp-idf : v3.2 for Case 3
Chip: ESP32- WROOM-32D
Flash : 16M (3M App + 9M FATFs)
Flash baud : 921600
CPU Freq : 240 MHz
Flash Freq : 80 MHz
Flash Mode : DIO
Debug Level : Info/Debug
Same behavior has been observed with latest Arduino version for ESP32 with esp-idf : v4.4.2 so it looks like have not been reported/fixed yet.
Case 1 : Arduino code on Arduino IDE : 4800 baud on UART0, ESP32 freezes and unable to undergo soft reset with partial output on Core 0 dump debug
Case 2 : idf code on Arduino IDE : 4800 baud on UART0, ESP32 freezes and unable to undergo soft reset with partial output on Core 0 dump debug
Case 3 : idf code on esp-idf : 4800 baud on UART0, ESP32 can undergo soft reset with full output on Core 0 dump debug
On further debugging, I found that the cut-off baud rate on UART0 to be 6207, below which the ESP32 freezes for any of the exception errors and is unable to reset. So it looks like very specific to the baud rate that is set
Sketch
Debug Message
Other Steps to Reproduce
None
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: