You risk bricking the device if the erase+write is interrupted for any reason, so imo it's worth avoiding this where possible. Unless these changes need to be backwards compatible, there's no need to literally alter the partition table. You can specify the partition in your esp_vfs_littlefs_conf_t, ...

There's nothing special about GPIO0 in this respect, so I would expect some bouncing from the tactile switch. There may be a capacitor which will filter out a bit of noise, but it may also cause boot issues so most designs exclude it. Even if this particular switch is very well-behaved you shouldn't...

The NVS component would be quite heavy for this imo, not to mention the significant effort of porting it to the bootloader. I would assign a single-sector (0x1000 bytes) partition for this purpose, and use basic flash operations to read and alter the setting: to get the current setting, read and cou...

1. Check the datasheet, "Appendix A – ESP32-S3 Consolidated Pin Overview": https://www.espressif.com/sites/default/files/documentation/esp32-s3_datasheet_en.pdf In the "At Reset" column, find a pin that is initialised in the desired state, taking care of strapping pins. Also check the S3 WROOM datas...

Use a "bootloader_before_init()" hook as in the example here: https://github.com/espressif/esp-idf/tree/master/examples/custom_bootloader/bootloader_hooks Since this is executed in the bootloader you'll need to be conscious of the limitations, in particular you'll need to use ROM functions where pos...

How to measure time? The RTC tick counter is 48 bits, so there's more than enough. True, you can only read 16 bits in one instruction, but you can use multiple instructions, or you can sacrifice some resolution at the lower end by reading RTC_SLOW_TICKS[18:3], for example. How to wait in program un...

Schematic for your board reveals a 10k pullup on GPIO2:

https://dfimg.dfrobot.com/nobody/wiki/3 ... 106295.pdf

Table 1-2, and section 1.3.2.1. There is nothing about ROM1 addressing via the instruction bus @ 0x40060000, however. I've only deduced this by literally comparing the contents of memory at these addresses. Give it a try to confirm for yourself, if you like. Knowing this, it's more intuitive to thin...

It looks like that needs to be updated. As far as I can tell, we can think of IROM as one contiguous 448K block @ 0x40000000, the last 64K of which is also byte-addressable over the data bus at 0x3ff90000 as "ROM1" (ie. ROM1 == 0x3ff90000 == 0x40060000).

It all comes down to how large your typical application binary is. If you configure your build for minimal size (especially by disabling logging) then you can squeeze a lot into a ~1MB partition. For reference, the factory app on the device next to me with WiFi STA+AP, HTTP/S client and server, resp...