Output hold no longer working (GPIO32 as example) (IDFGH-2489)

[revk]

I am using output hold, and now on latest IDF I find it no longer works. This meant after a s/w update I was locked in my office as the output hold on the lock before the update was not unlocked to open the door! Fun. I had to power cycle!

Anyway it seems hold and unhold functions on at least GPIO32 no longer work.

[revk]

I expected this to pop up with the usual template, sorry. It is latest esp-idf as of today. I think this came in with some HAL stuff for the S2 changes.

[revk]

For background, I have a door lock controller. I use output hold on GPIO32 all the time, unlocking to change and holding again. This means that a reset or crash does not open the door while resetting, which is obviously useful for security. The current esp-idf means that the door does unlock whilst resetting as the hold function is not working, and as I got locked in, that suggests unhold does not work either.

Using gpio_hold_en() and gpio_hold_dis() functions. Not using RTC/ULP modes at all.

[negativekelvin]

Old
SET_PERI_REG_MASK(rtc_gpio_desc[gpio_num].reg, rtc_gpio_desc[gpio_num].hold);

New
REG_SET_BIT(RTC_CNTL_HOLD_FORCE_REG, rtc_io_desc[rtcio_num].hold_force);

[fuAlex]

Hi revk, I have test your issue, but not recurrence. Please let me know your case.
This is my test code. Pls refer to ...

void app_main(void)
{
    gpio_config_t io_conf;
    io_conf.intr_type = GPIO_PIN_INTR_DISABLE;
    io_conf.mode = GPIO_MODE_OUTPUT;
    io_conf.pin_bit_mask = GPIO_SEL_32;
    io_conf.pull_down_en = 0;
    io_conf.pull_up_en = 0;
    gpio_config(&io_conf);
    gpio_hold_en(GPIO_NUM_32);
    while(1)
    {
        gpio_set_level(GPIO_NUM_32, 1);
        vTaskDelay(1000/portTICK_PERIOD_MS);
        gpio_set_level(GPIO_NUM_32, 0);
        vTaskDelay(1000/portTICK_PERIOD_MS);
        printf("change io status\n");
    }
}

[revk]

Thank you for testing - It definitely locked me in, honest :-)
I am going on holiday for next month, but will see if I can re-test whilst on a ship!
If its helps, I had not used gpio_config(), but simply gpio_reset_pin() and then gpio_set_direction() to GPIO_MODE_OUTPUT

[negativekelvin]

Theory: old function was using hold but the new function is using hold_force so if hold was set then update firmware and soft reboot, hold is still applied the new code would try to unset hold_force and hold would stay enabled until you hard reboot.

current esp-idf means that the door does unlock whilst resetting

Must also have to do with the difference between hold and hold_force

[revk]

OK, call me thick (and I have read the data sheets, honest) but what's the difference between hold and hold-force?

[fuAlex]

@negativekelvin @revk Thanks for your mention.
On the ESP32 platform, the functions implemented by the two registers are the same. And the two are in an "or" relationship. i.e. rtc_gpio_desc[gpio_num].hold or rtc_io_desc[rtcio_num].hold_force can put the GPIO in the hold state.
So I will update the gpio driver like this: Clear the state of these both two registers hold bit in the gpio_hold_dis function.

[revk]

Ah, nice solution. Thank you.

[negativekelvin]

Well they aren't exactly the same, supposedly hold_force works with RTC_PERIPH domain powered off but hold doesn't? It doesn't really explain why the new sdk would not hold through a reboot and old does if that is what @revk is seeing.

[revk]

I held on old code, and rebooted, and found that while new code was running the pin was still held. If we have changed which is set, and they "or", that makes perfect sense. It suggests new code will work find for me, just the transition from old to knew got me locked in :-)

[revk]

Though if they do behave differently, maybe we should have separate calls?

[negativekelvin]

Yes, there are cases where someone may not want to hold_force