Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect factory reset after deep sleep (IDFGH-1536) #3800

Closed
ducalex opened this issue Jul 19, 2019 · 2 comments
Closed

Detect factory reset after deep sleep (IDFGH-1536) #3800

ducalex opened this issue Jul 19, 2019 · 2 comments
Assignees

Comments

@ducalex
Copy link

ducalex commented Jul 19, 2019

Environment

Development Kit: Lolin32
Kit version
Module or chip used: ESP32-WROOM-32D
IDF version: v3.3-beta1-849-g630ffde6b
Build System: Make
Compiler version: crosstool-ng-1.22.0-80-g6c4433a5
Operating System: Windows
Power Supply: USB

Problem Description

If the factory reset gpio is asserted while booting from deep-sleep then the application is started with a possibly incorrect state because of preserved RTC memory but possibly different boot image and gone nvs and assumption that the firmware running before deep-sleep was the same.

Expected Behavior

One of three things:

  • The boot loader should do a clean restart after a factory reset during deep-sleep wake up
  • Or The factory reset should happen only on POWERON_RESET
  • Or The IDF gives us a way to detect that a factory reset just occurred

Actual Behavior

The application boots thinking it just woke from normal deep sleep and assumes its RTC variables and previous boot image are the same.

Steps to repropduce

  1. Set factory reset gpio to 15
  2. Set gpio 15 as a wake up source for deep sleep
  3. Go to deep sleep
  4. Hold gpio 15

Code to reproduce this issue

Debug Logs

Other items if possible

@github-actions github-actions bot changed the title Detect factory reset after deep sleep Detect factory reset after deep sleep (IDFGH-1536) Jul 19, 2019
@negativekelvin
Copy link
Contributor

negativekelvin commented Jul 20, 2019

Good suggestion. How about something like

#ifdef CONFIG_BOOTLOADER_FACTORY_RESET
        RESET_REASON rst_res = rtc_get_reset_reason(0);
        uint32_t is_rev0 = (GET_PERI_REG_BITS2(EFUSE_BLK0_RDATA3_REG, 1, 15) == 0);
        if(rst_res == POWERON_RESET || (is_rev0 && rst_res == RTCWDT_RTC_RESET)) {
            if (bootloader_common_check_long_hold_gpio(CONFIG_BOOTLOADER_NUM_PIN_FACTORY_RESET, CONFIG_BOOTLOADER_HOLD_TIME_GPIO) == 1) {
                ESP_LOGI(TAG, "Detect a condition of the factory reset");
                bool ota_data_erase = false;
#ifdef CONFIG_BOOTLOADER_OTA_DATA_ERASE
                ota_data_erase = true;
#endif
                const char *list_erase = CONFIG_BOOTLOADER_DATA_FACTORY_RESET;
                ESP_LOGI(TAG, "Data partitions to erase: %s", list_erase);
                if (bootloader_common_erase_part_type_data(list_erase, ota_data_erase) == false) {
                    ESP_LOGE(TAG, "Not all partitions were erased");
                }
                return bootloader_utility_get_selected_boot_partition(bs);
            }
        }
#endif

@ducalex
Copy link
Author

ducalex commented Jul 21, 2019

@negativekelvin That seems reasonable and the safest option.

Thank you for your code, I will use it for my current project and I hope that it eventually makes its way in esp-idf!

@igrr igrr closed this as completed in 69f45c3 Aug 30, 2019
igrr pushed a commit that referenced this issue Sep 16, 2019
igrr pushed a commit that referenced this issue Sep 20, 2019
igrr pushed a commit that referenced this issue Sep 21, 2019
igrr pushed a commit that referenced this issue Sep 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants