ESP32 Forum

Hi,
I have a custom board with module ESP32-S3-WROOM-1(N16R8).
My application is battery powered and simultaneously will be waken up frequently for short time.
So I need ESP to stay for most time in Deep-Sleep, and shorten the Run-time to minimum.

Currently the booting takes 96ms, I hoped I can reach <10ms.

I have already made following, that helped:
1) app_main() calls
esp_log_level_set("*", ESP_LOG_ERROR); // set all components to ERROR level

// for next wake-ups, no need for the booting debug messages
esp_deep_sleep_disable_rom_logging(); // suppress boot messages

2) in Menuconfig is set:
Bootloader config --->
Bootloader optimization Level: Optimize for performance (-O2)
Bootloader log verbosity: No output
[x] Skip image validation when exiting deep sleep

Component config --->
ESP32S3-Specific --->
[*] Support for external, SPI-connected RAM
SPI RAM config --->
[ ] Run memory test on SPI RAM initialization (i.e. disabled)

3) there follows list of things, that I tried and they had no effect:
- changed CPU freq from 160 to 240 MHz (it made difference maybe 1ms)
- config Boot ROM Behavior --->
Permanently change Boot ROM output: Permanently disable logging,
not possible, it caused it keeps self-resetting:
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
- config Serial flasher config --->
'idf.py monitor' baud rate (115200 bps) ---> 921600 bps
+ also changed in platformio.ini :
monitor_speed = 921600
- config Serial flasher config --->
Flash size: 16 MB
[ ] Detect flash size when flashing bootloader (i.e. disabled)
- config SPI RAM config --->
[ ] Initialize SPI RAM during startup (i.e. disabled)

4) what I can't do:
Flash must be (is) configured DIO, because setting Quad-IO causes crashing when ESP-IDF 4.4.2 is used.
Previous 4.4.1 was configured Quad, but I need 4.4.2 as it fixes some Reset when switching to Deep-Sleep.
So, not possible to speed-up Flash this way.

5) whatever I did, it still prints following log-messages on wake-up from Deep-Sleep, it probably wastes some time:
I (32) spi_flash: detected chip: gd
I (33) spi_flash: flash io: dio
I (83) sleep: Configure to isolate all GPIO pins in sleep state
I (84) sleep: Enable automatic switching of GPIO sleep configuration
I (86) cpu_start: Starting scheduler on PRO CPU.

Is there anything else that could shorten the boot-up time ?
Is there anything that could completely deactivate all boot-log messages ?

Hi,

Thank you for the list of option to reduce boot time.
I am using ESP32-C3 and SDK5:
- Permanently change Boot ROM output: Permanently disable logging - works fine, no output from ROM.
- setting Quad-IO - works fine, reduce few msec

maybe you can move to SDK5 and you can save few more msec...
how did you measure "Currently the booting takes 96ms"?
I can measure bootloader + app but I don't know when rom is starting after wakeup from deep sleep? (for me it is about 67msec for bootloader and app time from deep sleep (at CPU max speed 160Mhz )

I have the same requirements: the ESP32-S3 should run only 5ms every second. However the boot time is much much higher.

I guess that the main reason is that the program code is transferred from Flash to SRAM, am I correct? (for a program having 300kbytes: ~3,000,000 bits x 1Mbit/second = 3 seconds! I am not sure at all about the transfer speed, though).

I thought that using the "Direct Boot" option of the "SPI Boot mode" (see technical reference, chapter 8), I would avoid this, by having the code executed directly from the Flash.

However:
1) this project from Espressif (https://github.com/espressif/esp32c3-di ... /README.md) lists the good reasons of using this mode, but the shortening the boot time is not among these reasons.
2) it seems extremely complex to implement (see the "ld" subdirectory of this project).

Can you please let me know your thoughts and recommendations?
Many thanks!

bfredo123 wrote: ↑

Sat Oct 05, 2024 3:02 pm

I have the same requirements: the ESP32-S3 should run only 5ms every second.

Sounds like you'd need light sleep instead of deep sleep in this case.

I guess that the main reason is that the program code is transferred from Flash to SRAM, am I correct?
...
I thought that using the "Direct Boot" option of the "SPI Boot mode" (see technical reference, chapter 8), I would avoid this, by having the code executed directly from the Flash.

Most of an application's code actually is executed directly from flash.
Only parts of the code (IRAM_ATTR) are loaded into RAM upon initialization. You can see it for example in the log messages during boot: "esp_image: segment ... size=XXXX ( YYYY) load". (Unless you enable Execute from PSRAM.)