Not sure where you get USB_SEL from, in hardware and the bootloader GPIO18 doesn't have any specific function. In general, you should always be able to upload new code when you force-boot into download mode (GPIO0 and GPIO46 low while the chip comes out of reset).

Yes. You can always (that is, unless you have actively messed with fuses to e.g. put the chip into SecureBoot mode) get an ESP32 back into download mode. On the C3, you do that by pulling down GPIO9 (and GPIO8 up if needed) and making reset low for a moment. If you're using a development board ...

It's probably because we didn't bother to test anything above 400kHz. It probably works fine; the silicon itself isn't really that constrained; if you get any issues it may be because of (analog) setup/hold time violations, or if you go really high in speeds (10s of MHz) you might run into the limit ...

Again, might be a baud rate error. Have you tried scoping out the serial signal, see what time the shortest pulses on the line take? 1s/that is your baud rate.

You could use unnamed members and then offsetoff(first_member) to get the byte offset of a block (and the same trick for the length).

I don't recall the exact efuse situation, but it could be you're hitting intended behaviour. USB-OTG (as the ESP32-S2 has) needs a large driver to work as a serial port, and as a large driver also gives a large attack surface, it's disabled if you go into secure boot mode. I think this affects both ...

EN should indeed be high for the chip to work; you normally want to put a power-on reset RC network on there. See the hardware guidelines for that chip for an example. It's odd that you get garbage even with only a pulldown installed; I'd expect that to keep the ESP in reset and as such silent.

The ...

Not sure about autovectorization, but you can assume that given the S31 core is RiscV, the PIE will be (possibly a superset of) the PIE found in the ESP32P4.

I doubt it's the GPIO matrix - if that were to be broken, you wouldn't see any packets to begin with, and the matrix is a pretty simple and tested and tried peripheral. What does your hardware look like? (As in: show a picture, post PCB designs etc)

3) The issue seems to be caused by memcpy implementation in the new compiler. In my case the memcpy target was SPI_W0_REG - a register HW address for SPI transfer buffer. memcpy in the older compiler dealt with the data transfer to the HW register fine, the new compiler's memcpy did not. The fix ...