I'm using ESP32-D2WD on a custom board and have disabled the SPI code/GPIO setup/etc on the JTAG pins (GPIOs 12-15). After switching XMC Link to libusb driver, I am able to get this far from msys2 console: $ bin/openocd.exe -s share/openocd/scripts -f interface/jlink.cfg -f target/esp32.cfg Open On-...

I was able to solve this by changing rx_flow_ctrl_thresh from 122 to 40.

This update is working well. However, it seems to require reflash of the bootloader. Any suggestions for OTA? Should I just re-write the bootloader in the field (seems risky)?

I'm suspecting the VSDIO line, as all of these issues started when we moved to 1.8V from 3.3V. Can you elaborate on what this means? Unfortunately, if you had MTDI strapped to 3.3V for an extended period, the flash itself may be damaged. I have older devices that ran at 3.3V that starting having is...

Or should I consider raising the flash voltage to 3.3V for erase/flashing operations? I am noticing some dirty erase cycles where I have to do a blank check and re-erase once or twice to actually get a 0xF0000 block cleared.

I'm suspecting the VSDIO line, as all of these issues started when we moved to 1.8V from 3.3V. We have close to 100uF on the 3.3V main rail, and the regulator is LT3973EDD-3.3. The VSDIO is using internal LDO and only has the recommended 1uF capacitor attached (very close to the pin) with no other t...

Seems so from this log, yes.

Great, thanks.

Also - is there a way I can disable caching of read/write operations to flash or do the partition read/write functions bypass caching?

This is at 1.8V, so strapping config is 10K to group from MTDO and 10K to 3.3V from MTDI. Nothing is connected to SD_DATA_0-3, SD_CLK, SD_CMD, GPIO16-17 - everything in the 1.8V domain, except 1uF to ground on VDD_SDIO. Thanks.