Espressif: Update to ESP-IDF v5.4.1 #10191
Comments
|
I encountered build problems with the espressif port this morning. It looks like ESP-IDF's tools include overcomplicated fragile Python dependency check scripts. Is this related? A temporary fix was |
|
@AbortRetryFail There are known python package version conflicts between CircuitPython and ESP-IDF. In a nutshell, you'll need to run |
eightycc
changed the title
|
ESP-IDF 5.4.1 is the current release version. If there's no objection, I'll fit our local commits onto upstream tag v5.4.1. |
|
Yes, please rebase changes on https://github.com/adafruit/esp-idf/tree/circuitpython-v5.3.2 onto a new |
|
ESP-IDF does more strict checking for valid use of CONFIG_ flags. It now checks that all used flags are defined somewhere in the chain of Kconfig files for the target processor. This applies not just to flags that are defined, but also to flags that are commented out. Although CP does not use Kconfig, these checks are still performed. CP config files all pass, except when building for the ESP32H2. CP configures this for a 48 MHz flash spi clock, but according to Kconfig this isn't a valid setting. The valid setting are 16, 32, and 64. Is this a typo in CP or a setting we want? I've added support to ESP32H2 Kconfig for a 48 MHz clock. |
|
Symbol |
|
The symbol |
|
With a |
|
It turned out this double faulting crash only occurs with |
|
@dhalbert My earlier thought that ESP-IDF component vfs was not needed was incorrect. After studying the doc and the code I now see that it is used internally by IDF for console and socket support. Debugging is also a learning experience. Through a process of setting hardware breakpoints, I've narrowed the point of failure down to a binary routine in the ESP32 ROM. The routine itself is void esp_newlib_init_global_stdio(const char *stdio_dev)
{
if (stdio_dev == NULL) {
_GLOBAL_REENT->__cleanup = NULL;
_REENT_SDIDINIT(_GLOBAL_REENT) = 0;
__sinit(_GLOBAL_REENT);
_GLOBAL_REENT->__cleanup = esp_cleanup_r;
_REENT_SDIDINIT(_GLOBAL_REENT) = 1;
} else {
_REENT_STDIN(_GLOBAL_REENT) = fopen(stdio_dev, "r");
_REENT_STDOUT(_GLOBAL_REENT) = fopen(stdio_dev, "w");
_REENT_STDERR(_GLOBAL_REENT) = fopen(stdio_dev, "w");
#if ESP_ROM_NEEDS_SWSETUP_WORKAROUND
/*
- This workaround for printf functions using 32-bit time_t after the 64-bit time_t upgrade
- The 32-bit time_t usage is triggered through ROM Newlib functions printf related functions calling __swsetup_r() on
the first call to a particular file pointer (i.e., stdin, stdout, stderr)
- Thus, we call the toolchain version of __swsetup_r() now (before any printf calls are made) to setup all of the
file pointers. Thus, the ROM newlib code will never call the ROM version of __swsetup_r().
- See IDFGH-7728 for more details
*/
extern int __swsetup_r(struct _reent *, FILE *);
__swsetup_r(_GLOBAL_REENT, _REENT_STDIN(_GLOBAL_REENT));
__swsetup_r(_GLOBAL_REENT, _REENT_STDOUT(_GLOBAL_REENT));
__swsetup_r(_GLOBAL_REENT, _REENT_STDERR(_GLOBAL_REENT));
#endif /* ESP_ROM_NEEDS_SWSETUP_WORKAROUND */
}
}The second call to |
|
This looks similar to the code in https://github.com/adafruit/nina-fw/blob/dfc0c299719891002a8b99c187c6532f2d1ce8f9/main/sketch.ino.cpp#L64 I mentioned in discord, which I had to turn off because it was causing an early crash. Might be worth looking in esp-idf issues to see if there are similar reports. |
|
@dhalbert The blob you reference tickles exactly the same spot: early initialization of |
|
Here's the exact issue, now closed: espressif/esp-idf#7980. I'm now looking for something stale CP's ESP-IDF config. |
Espressif: Update to ESP-IDF v5.4
The text was updated successfully, but these errors were encountered: