ESP32C6 ROM Bootloader resets PMU_TIE_HIGH_HP_PAD_HOLD_ALL upon boot (IDFGH-12130)

[t-moe]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm on the esp32c6 and I want to keep the output state of a GPIO pin low during deep sleep.

• First the output in question (e.g. gpio22) is set low.
• Then, before entering deep sleep, I set the PMU_TIE_HIGH_HP_PAD_HOLD_ALL flag to 1.
• I enter deep sleep (with wakeup source of some other lpio gpio e.g. gpio0)
• During deep sleep the pin (gpio22) indeed hold its state (low)
• After wakeup (e.g. with IO interrupt) the pin immediately turns to high, as soon as the ROM bootloader starts.

I've used the esp32 rust driver, but I think it is a ROM bug, because the part up and including sleeping works as expected.

Can you advise here?

[esp-wzh]

Thank you @t-moe for reporting this problem, I think this problem should exist on all esp chips, the reason to unhold all IOs in ROM boot is to avoid that the IOs of key system peripherals such as SPI /UART are held before reset making it impossible continue to run the flash boot.

Currently, if you want to avoid this wrong signal, you can use LP_IOs, which on esp32c6 are GPIO0~7, they don't lose configuration during deepsleep, so there is no pulse signal even if they unhold. Refer https://github.com/espressif/esp-idf/blob/master/components/esp_driver_gpio/include/driver/rtc_io.h

We are evaluating the reasonableness of this requirement, I'll update in this thread if there's any progress

[t-moe]

Hi @esp-wzh,
Thanks for your response.

We also found that we can successfully hold a GPIO8..GPIO30 if we set the corresponding LP_AON_GPIO_HOLD0_REG[n] bit. This seems to work with the current ROM. This probably works in our case, as a workaround. I hope this continues to work and you dont extend the ROM in future versions to also unhold this upon boot.

Regarding the initial problem:
I understand the reasoning behind the current ROM implementation, but I would expect that the technical reference manual contains a warning near the PMU_TIE_HIGH_HP_PAD_HOLD_ALL documentation. Can you add this? Also, is the "Hold all" esp32c6 specific?

Thank you

[esp-wzh]

@t-moe I figured it out! the hold en signal for gpio[n] is arbitrated out by the following logic,

so there is no problem with the ROM, I have suggested to documentation colleague to add a description in this section, thanks for your feedback!

[t-moe]

Not sure we're talking about the same thing here. Here is what I tried to communicate:

• My initial bug report mentioned that the "global hold all" is cleared by the rom (by setting PMU_TIE_LOW_HP_PAD_HOLD_ALL ?). I think this is still the case (?), and should be documented in the reference manual.

• But yes, not setting the "global hold" and only setting the individual hold (LP_AON_GPIO_HOLD0_REG[n]) works and the rom bootloader does not reset the individual holds.

[esp-wzh]

Got it, we will add these two notes to the document.