I think it depends on what kind of reset is performed and whether the clocks were stopped. For instance, if you toggle the EN/CHIP_PU line, that's a power cycle of the chip.

I think the only real way to recover the time locally would be to include an I2C RTC with a battery backup.

All right. Lets supose that user1 creates the repository and initializes the project. Said user adds BUILD and .vscode to the gitignore. Now user2 clones the repo and tries to start working. The .vscode folder will not automatically be generated? How does he have to proceed? I'm not a vscode expert...

Make sure that the ".vscode" and "build" directories aren't checked into git. They should be user-specific.

* GPIOs 35, 36, and 37 are used to support the octal internal SPI and aren't available for general use. Note that this is also true for WROOM-1 modules that use octal flash or PSRAM. Ah that makes sense. I also use the DevKit C boards with the quad modules and the fact that those gpios aren't avail...

Just a couple of notes on the wroom-2... * GPIOs 35, 36, and 37 are used to support the octal internal SPI and aren't available for general use. * The internal SPI voltage is 1.8v, not 3.3v (not usually a concern). Startup does emit some warnings indicating that timings will be updated in the future...

Exactly what chip/board are you running on?
What version of ESP-IDF are you running?
Did you modify any of the code?

You may want to erase the flash and try again.

Thank you for answering so quickly. I would like an example of using fatfs to access the devkit c 4mb.

That's exactly what the wear_levellling example does.

PD: are there any examples of writing a firmware bin file into the fatfs?

Not that I'm aware of.

It depends on what the underlying storage is, the on board spi flash, external flash in spi mode or external flash in sdmmc/sdio mode, but the simplest example for the on-board flash is under wear-levelling... https://github.com/espressif/esp-idf/tree/release/v4.4/examples/storage/wear_levelling Oth...

The short answer is that "yes, calling gpio_set_leve() should work". I believe that it will take effect although I can't test it right this second. gpio_set_level() checks that the gpio can be an output pin but not whether it's currently set as an output pin. It then updates the gpio driver structur...

Did you unmount it with esp_vfs_fat_spiflash_unmount before you invalidated the partition?
You're not going to be able to mount it a second time to the same mountpoint without doing that first.