[ESP32] Using sys_poweroff makes Zephyr unbootable

[mari-rv]

Describe the bug

Simply by adding sys_poweroff() in the application code, the application does not boot.

• Target platform: platform specifiers esp32_devkitc_wroom/esp32/procpu and esp32s3_devkitc/esp32s3/procpu
• Things I've tried: using esp_deep_sleep and esp_deep_sleep_start functions directly instead of calling sys_poweroff. I also tried starting a fresh Zephyr west workspace in my personal laptop to check if the problem is still present, and it is. Right now I'm suspecting there's a problem with my ESP32 chips...

The behavior is very weird. My application used to work in a commit between v4.0.0-rc3 and v4.1.0-rc1, but now it doesn't work at all even in v4.0.0-rc3

To Reproduce

The sample samples/boards/espressif/deep_sleep does not boot in v4.1.0-rc1, and triggers TG0WDT_SYS_RESET right after DEEPSLEEP_RESET (see logs and console output).

Steps to reproduce:

• In v4.0.0-rc3:
  1. Change Zephyr revision to v4.0.0-rc3 and run west update
  2. In the root of Zephyr repository, run: west build -p always -b esp32_devkitc_wroom/esp32/procpu --no-sysbuild samples/boards/espressif/deep_sleep
  3. Flash the code
  4. Zephyr boots, but triggers TG0WDT_SYS_RESET right after DEEPSLEEP_RESET
• In v4.1.0-rc1:
  1. Change Zephyr revision to v4.1.0-rc1 and run west update
  2. In the root of Zephyr repository, run: west build -p always -b esp32_devkitc_wroom/esp32/procpu --no-sysbuild samples/boards/espressif/deep_sleep
  3. Flash the code
  4. Zephyr never boots

Expected behavior

Application performs deep sleep and wakes up accordingly.

Impact

I'm still relatively new to Zephyr, I like Zephyr so much since I first tried it, and I'm porting some ESP-IDF projects to Zephyr. This is kind of annoying since it's blocking me from developing further my application.

Logs and console output

• Screenshot of console output of samples/boards/espressif/deep_sleep application on v4.0.0-rc3:
  
  And then, the program proceeds to run as if it was booting for the first time.
  Note: there's a 1 ~ 5 seconds delay between TG0WDT_SYS_RESET and DEEPSLEEP_RESET resets

• Screenshot of console output of samples/boards/espressif/deep_sleep application on v4.1.0-rc1:
  
  And then, nothing ever happens after the last line...

Environment (please complete the following information):

• OS: Debian Linux 12
• Toolchain: Zephyr SDK 0.17.0
• Zephyr revisions: v4.0.0-rc3 and v4.1.0-rc1

Additional context

My application used to work in revision b7cfa54c18374eeeec141326fcc7052c7d1078fc for a long time. My application involves the use of a generic GNSS device on uart2, a LoRaWAN device on uart1, an IMU on i2c0 bus and a sdmmc on spi2. My development flow was:

1. Use the gnss-nmea-generic compatible driver
2. Implement IMU driver
3. Implement deep sleep logic
4. Implement sdmmc filesystem utilities
5. Implement LoRaWAN driver on uart

Steps 1 through 4 worked fine, but as soon as I implemented my LoRaWAN driver, my application became unbootable. I tried to diagnose what's going on by starting a fresh application from samples/hello_world sample and adding one component after another. It was weird because I added the LoRaWAN and GNSS drivers first and my application booted, but as soon as I added the deep sleep code, it didn't boot anymore. I'm not really sure what causes this, but I at least managed to reproduce it in a clean environment.

Screenshot of my application working in the revision b7cfa54c18374eeeec141326fcc7052c7d1078fc:

Might be related to #86192

[mari-rv]

I was just testing some things, and noticed that the sample works if using MCUBoot (e.g. compiling using --sysbuild argument). It works on revisions v4.1.0-rc1 and v4.1.0-rc2. I tested both on ESP32 and ESP32S3 and it works.

Basically, it only doesn't work when using the simple bootloader.