Closed punkto closed 1 month ago
Thanks for reporting!
Yeah that seams to not include all possibility's.
Are you interested in a PR to include the missing variants?
We only have to check that we don't include them for targets where a reset reason does not exist. If the underlying C type is the same for every target than its not a problem.
Hi @Vollbrecht , thanks for your support.
Before a PR, please let me se if I'm understanding what is going on. It seems that the IDF has a common esp_reset_reason_t for all the targets at https://github.com/espressif/esp-idf/blob/master/components/esp_system/include/esp_system.h#L24 :
typedef enum {
ESP_RST_UNKNOWN, //!< Reset reason can not be determined
ESP_RST_POWERON, //!< Reset due to power-on event
ESP_RST_EXT, //!< Reset by external pin (not applicable for ESP32)
ESP_RST_SW, //!< Software reset via esp_restart
ESP_RST_PANIC, //!< Software reset due to exception/panic
ESP_RST_INT_WDT, //!< Reset (software or hardware) due to interrupt watchdog
ESP_RST_TASK_WDT, //!< Reset due to task watchdog
ESP_RST_WDT, //!< Reset due to other watchdogs
ESP_RST_DEEPSLEEP, //!< Reset after exiting deep sleep mode
ESP_RST_BROWNOUT, //!< Brownout reset (software or hardware)
ESP_RST_SDIO, //!< Reset over SDIO
ESP_RST_USB, //!< Reset by USB peripheral
ESP_RST_JTAG, //!< Reset by JTAG
ESP_RST_EFUSE, //!< Reset due to efuse error
ESP_RST_PWR_GLITCH, //!< Reset due to power glitch detected
ESP_RST_CPU_LOCKUP, //!< Reset due to CPU lock up
} esp_reset_reason_t;
and the per target reasons (for example https://github.com/espressif/esp-idf/blob/v5.2.1/components/soc/esp32c2/include/soc/reset_reasons.h ) are boiled down to these at their respective get_reset_reason()
like in https://github.com/espressif/esp-idf/blob/master/components/esp_system/port/soc/esp32c61/reset_reason.c#L19
If this is the case, we just need to add the last reasons to ResetReason and update the from
method. That will work with all the targets as the c part is doing the per target part. Isn't it?
PS: Why are not ESP_RST_EFUSE, ESP_RST_PWR_GLITCH and ESP_RST_CPU_LOCKUP in bindings.rs ?
The condition can look something like
#[cfg(not(any(
esp_idf_version_major = "4",
all(esp_idf_version_major = "5", esp_idf_version_minor = "0"),
)))] // ESP-IDF 5.1 and later
``
Ah, and in v5.2.2 they added ESP_RST_EFUSE, ESP_RST_PWR_GLITCH or ESP_RST_CPU_LOCKUP, that answers my PS question.
Let me prepare a PR...
On reset reason translation from IDF code to ResetReason struct at https://github.com/esp-rs/esp-idf-hal/blob/master/src/reset.rs#L34 the code panics if the reset reason is not in a subset of all reasons. In the bindings.rs generated from esp-idf-sys version "0.34.1" the reasons are:
Reasons with code greater than 10 are not included in the translation.
I have a board with an ESP32c3 module that on first boot after flashing it panics. The code is this (https://gitlab.com/scrobotics/optical-makerspace/dark-sky-meter-fw/-/blob/104-app-panics-just-on-first-boot/examples/panics_on_reset_reason.rs?ref_type=heads):
the output after flashing is:
I have also tested with an ESP32-C3-DevKit and the reset reason is different (maybe that is the reason because it has not been issued earlier):