How specifically did you try to erase the flash; can you post e.g. the esptool command line here?

I can confirm that that ESP32 devboard is not optimized for low power use; the LDO has a pretty high quiescent current and from memory, current can leak away through the USB-serial chip. (Also note that the board you show is some unnamed third party board, I don't think Espressif made it.) The block...

That is a valid approach.

Hm. If your functions were entirely standalone (as in: no internal global variables, no calls out) you could technically load it in RAM and execute it. That's not something that's widely supported, so I don't have any docs to point you at. Perhaps as an alternative, you can implement some fixed DSP ...

That I cannot explain. Perhaps something's up with the USB side of things? Perhaps adding or removing a hub may work?

As in: nothing in the flash, brand new, entirely empty? The issue then could be that the RTC watchdog resets the ESP every few seconds or so, making the USB interface re-enumerate. That can make it a bit hard to connect to the chip to get into download mode (as in: you need to have the luck that the...

Not trivially. Could you elaborate a bit more about your use case? Perhaps there are other ways to accomplish this.

Looking at the GPIO driver code, the bit that makes the GPIO an output also muxes it back to being a plain old GPIO instead of being connected to the RMT. You can either reconnect the GPIO to the RMT using esp_rom_gpio_connect_out_signal(), or use the HAL directly and call gpio_hal_output_enable(), ...

0x1600000 is not 16M. You want 0x1000000.

One of the options you haven't mentioned is that something goes wrong in the middle of polling your server, and somehow your code keeps waiting for some answer while none comes: it's working exactly as coded and the hardware is fully functional (so the wdt doesn't catch you) but your device still is...