FWIW I have long abused the RTC_x_DATE_REG registers on ESP32 without issue. They don't seem to have any purpose and are RW.

That seems to have done the trick! Thankyou

The new anti-bot measures seem to be messing up the RSS feed.

I'm guessing my RSS client (Aggregator on Android) is hitting the "stupid bots" check, and failing on invalid XML. It seems to occur if I haven't visited the forum for a few days or perhaps it's whenever I get a new IP, and resolves ...

I do this with almost all of my ESP32 projects. Never had any issues. I point the VS Code extension at the directory (.esp-idf) and I'm off to the races. I still use the common "tools" path as I very rarely go breaking things in there.

My understanding is that the read-flash command can't decrypt the encrypted flash contents during the transfer, so I would expect the entire file of downloaded data to be "gibberish", including the empty parts of the flash, because "decoding" the empty data (0xFF) will result in garbage data ...

What do you mean by a full RTC reset?


There are a few different types of "resets", of which only an RTC reset completely restores all registers to default values, equivalent to a power-on. A lot of state can persist over the softer resets, which can cause rare and difficult bugs like the one ...

You can interrupt directly:
https://github.com/espressif/esp-idf/bl ... iscv.h#L59

Could you try rtc_hal_ext1_clear_wakeup_status() after configuring the pin?

Or you could always do a full RTC reset (eg. using RTC WDT). That fixes everything.

No. Only a few GPIO functions are placed in IRAM, and gpio_intr_enable is not one of them:
https://github.com/espressif/esp-idf/bl ... r.lf#L4-L7

SRAM1 is accessed over the data bus at 0x3fc88000 or the instruction bus at 0x40378000. It's the same physical memory. When you clear 0x3fc88000 you are also clearing 0x40378000.