v5.2 bootloader crashes on startup (IDFGH-12141) #13197
Comments
github-actions
bot
changed the title
|
This issue persists on release/v5.2 as well: cc649ea DO NOT USE THIS RELEASE Absolute fail y'all. I'm going back to 5.1 - please do not suggest updating to 5.2 to deal with the bugs in 5.1 until 5.2 is able to boot up the chip. |
|
I can confirm that reverting IDF to v5.1 is a viable fix. |
|
Sorry for the bad experience with the version upgrade @readmodifywrite! There haven't been many changes since v5.2-beta1 release, and so far we didn't get feedback that it's absolutely broken, so we went ahead with the final release. In our internal CI, all IDF examples we test on real hardware also worked fine. However sometimes there are cases which are not covered by our CI, usually related to a particular combination of sdkconfig settings. Hopefully we can figure out what is causing the issue in your case quickly. According to the log, the crash happens during app startup (cpu_start line). Could you please clarify if you are
Additionally, could you please use |
|
Everything is built on 5.2. It never gets to the app binary. I'm loading over serial with esptool. I don't have the sdkconfig at the moment, I've already reverted to 5.1 and am now trying to unfuck the mDNS build which refuses to work without the useless component manager. I'm sorry I can't be more helpful, but it's just whack-a-mole with broken behavior in the IDF. I've got a ton of issues with the MQTT client I'm trying to sort out too (was hoping 5.2 would clean some of this up, apparently it won't). There is just too much instability, unnecessary complexity, and change for the sake of change for me to keep up. It's a full time job just to workaround bugs in the IDF, and I'm just a solo dev. At some point I need to write my actual app code so I have a product to sell! |
The If you manage to share the sdkconfig file and provide the decoded backtrace in the future, it would be very helpful for diagnosing this issue. |
|
FWIW, y'all really do an amazing job of support here. No other chip vendor even bothers to try. I'll try and dig a bit more on 5.2 next week - I need to circle back to my MQTT stuff for now. I did get the mDNS sorted so that's something. |
|
Seems like the user app crashed immaturely when the default console is configured as USB Serial JTAG. |
|
Hello @readmodifywrite, |
|
Here is an MWE for this issue. IDF version: v5.2-166-ge0944287f3 (e094428) main/main.c #include <freertos/FreeRTOS.h>
#include <stdio.h>
void app_main(void) {
while (1) {
fputs("hello world!\n", stderr);
vTaskDelay(1000);
}
}main/CMakeLists.txt idf_component_register(SRCS "main.c")CMakeLists.txt cmake_minimum_required(VERSION 3.16)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(tester)sdkconfig.defaults Log messages
|
|
Updated to 5.2 and killed 4 hours trying to figure out why my app won't boot. That was not very fun. I confirm the issue, turns out it happens to me with USB-Serial as default output. esp32-c3 v0.3, linux |
|
We've also confirmed that there is indeed an issue with using Thanks for the feedback here which helped us find the issue and sorry for all inconvenience this has caused you guys when trying to upgrade to v5.2! |
|
Any updates on this issue? |
Seems to be fixed on latest dev branch. If you go to my issue that is closed i explain exactly where/what line the issue is. |
|
Issue was fixed on master with 6768805, but unfortunately that introduced a regression with usb_otg console. My colleague is working on fixing that, and as soon as it is working properly we will merge both fixes to v5.2. |
|
FYI: esp32c3 issue is present too with |
@ESP-Marius @mythbuster5 |
|
Yes, this should be fixed as per the referenced commit. Seems like the issue didnt close automatically. If anyone is still seeing these issues then please feel free to re-open this ticket. |
espressif-bot
added
Status: Done
|
Thanks for the quick work on this one! |
|
Sorry for bothering you, but I'm still encountering a similar issue after upgrading my IDF to I'm using the Despite this, my program still experiences a panic abort, although it now progresses to a later stage. I noticed that the commit message for 6768805 mentions "Fix wrong serial number that has been parsed to rom...", but the debug log before the panic abort shows an error indicating "uart_num error." I'm quite confused and would appreciate your help in resolving this issue. I've attached the debug logs below for your reference. Thanks a lot! Debug Logs: |
|
@sailinglove, I think this is unrelated to the bug reported earlier, as far as I can see It will try to initialize an UART driver using |
|
@ESP-Marius First of all thanks for the quick response! I looked again into the sdkconfig and found that Anyway, I am just trying to provide wifi ssid and password through |
Answers checklist.
IDF version.
v5.2 11eaf41
Espressif SoC revision.
ESP32-C3
Operating System used.
Linux
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
Development Kit.
Custom board
Power Supply used.
USB
What is the expected behavior?
The chip should boot up to the user application.
What is the actual behavior?
The bootloader crashes on startup.
Steps to reproduce.
Run IDF tag v5.2 on the C3.
Debug Logs.
More Information.
This is fatal for v5.2. This commit should not be tagged with a broken bootloader. Please delete the tag so no one else runs in to this.
What commit (I want the exact hash) on 5.2 actually works?
The text was updated successfully, but these errors were encountered: