Esp-idf version used for MP firmware.

[robert-hh]

This question may have been raised already, but I did not find the answer: which esp-idf version is actually used for the firmware images provided by MicroPython?

[fivdi]

To figure this out in the past, what I've done is searched for the strings idf and IDF in the firmware images provided by MicroPython.

For example, on Linux, running the command strings esp32-20220618-v1.19.1.bin | grep IDF displays:

MicroPython-1.19.1-xtensa-IDFv4.2.2-with-newlib3.0.0

Running the command strings esp32-20220618-v1.19.1.bin | grep idf displays:

/home/micropython/esp-idf-v4.2/components/freertos/tasks.c
/home/micropython/esp-idf-v4.2/components/freertos/timers.c
/home/micropython/esp-idf-v4.2/components/newlib/locks.c
idf_heap_info
/home/micropython/esp-idf-v4.2/components/driver/adc_common.c
/home/micropython/esp-idf-v4.2/components/driver/dac_common.c
/home/micropython/esp-idf-v4.2/components/driver/i2c.c
/home/micropython/esp-idf-v4.2/components/driver/i2s.c
/home/micropython/esp-idf-v4.2/components/driver/rtc_io.c
/home/micropython/esp-idf-v4.2/components/driver/touch_sensor_common.c
/home/micropython/esp-idf-v4.2/components/driver/esp32/touch_sensor.c
/home/micropython/esp-idf-v4.2/components/freertos/event_groups.c
Invalid coexist adapter function md5, internal: %s, idf: %s
Invalid OSI esp_wifi_os_adapter.h md5, internal: %s, idf: %s
Invalid WiFi esp_wifi_crypto_types.h md5, internal: %s, idf: %s
Invalid WiFi esp_wifi_types.h md5, internal: %s, idf: %s
Invalid WiFi esp_wifi.h md5, internal: %s, idf: %s
Invalid supplicant md5, internal: %s, idf: %s
/home/micropython/esp-idf-v4.2/components/esp_ringbuf/ringbuf.c
/home/micropython/esp-idf-v4.2/components/freertos/queue.c

On seeing this output I assume ESP-IDF v4.2.2 is being used. This technique probably isn't a bulletproof solution to figuring out which ESP-IDF version is being used but I'm not aware of a better solution.

[fivdi]

Here is another example, this time searching for the string v3 in an older firmware image with the command strings esp32-idf3-20190125-v1.10.bin | grep v3. The output is:

v3.2-dev-498-g30545f4cc
SSLv3.0

[robert-hh]

Thanks. I could have considered that. From the build scripts it is not clear whether v4.2.x or v4.4.x is used.

[jimmo]

We use 4.2 for the original ESP32 and 4.4 for all the new ones (S2, S3, C3, etc).

[bulletmark]

@jimmo , do you use 4.2, or 4.2.1, 4.2.2, 4.2.3, or 4.2.4?

[jimmo]

4.2.4

[jimmo]

Argh, typo. I meant to say 4.2.2

[cwalther]

If installing and running the image is an option, try (on reasonably recent versions)

>>> import platform
>>> platform.platform()
'MicroPython-1.18.0-xtensa-IDFv4.2.2-with-newlib3.0.0'

(That seems to be the first string found by @fivdi.) (Here is where the question was raised before.)

[robert-hh]

Thanks. I always forget the platform module.

[bulletmark]

If installing and running the image is an option, try (on reasonably recent versions)

>>> import platform
>>> platform.platform()
'MicroPython-1.18.0-xtensa-IDFv4.2.2-with-newlib3.0.0'

The platform module seems to be completely missing from the documentation, or I am not looking correctly?

[mattytrentini]

You're right, there is no documentation for it. 😞 We'll need to fix that. In the meantime, the PR that introduced the module explains things - see #7730.

[bulletmark]

All that integration/coverage checking and nothing flags that there is no documentation for the new module?! That's what should be fixed I suggest. Thanks for the reference.

[IhorNehrutsa]

I propose to stop supporting version 4.2.

[IhorNehrutsa]

ESP32: support ESP-IDF v5.1.2 #12952