If you want to use load_ram option, make sure that the application doesn't have any sections placed into flash. Esptool points out that there is a section mapped at 0x40080000, which is the base address of memory-mapped flash region. You can check the sections of the elf file using 'xtensa-esp32-elf...

Light sleep will not be supported in the next version (2.1) yet. Most likely it will be supported in the one after that. This means that it should be available in about two months.

Ah, okay, "If you try to avoid a.) with an own external 1.8V supply" was the part I didn't get from your previous post. No, we're not suggesting to use an external supply. Setting the strapping pin to the correct level for the D2WD should be sufficient. Documentation will be updated to explain this ...

If you use a hypothetical 3.3V pSRAM and a 3.3V flash, both powered from VDD_SDIO, and you configure the internal LDO by means of an Efuse or a strapping pin, then there should be no issues with deep sleep. That being said, i do not understand what kind of problems you mean by "eFuse Deep-Sleep prob...

In the current chip there doesn't appear to be a way to solve this automatically. Essentially you need to provide backup power supply which can last long enough to let the application detect loss of power and enter deep sleep. Detecting loss of power can be done using a GPIO interrupt. Entry into de...

There is an official API for sending 802.11 frames coming to the SDK in a few days. It has the same limitations as on the 8266 (no management frames) but that should be okay for your use case.

The issue we had was due to the fact that the 1st and 2nd revisions of ESP-WROVER-KIT boards had an incorrect value of capacitors connected to XTAL pins. This was fixed in the 3rd revision of the board. With a custom board, check the values you are using.

the ""{\"pwr\":\"off\"}\r\n"" should come after all the headers and the newline (\r\n), not in between the headers.

Note that your wiring should be as described in the example readme, and there should be a pullup resistor on the card's D3 line, even if you are using it in a single lane mode.

If you use 'make monitor' tool in ESP-IDF, you can get the readable backtrace (file names/line numbers). What happened here is that some code has terminated the program by calling 'abort()'. The backtrace can give you a hint what could be the reason for that.