The TRM, mostly. The way the SPI registers are built strongly hint at QIO etc being a per-transaction thing you can enable on any CS.

I think that may be misleading. As far as I can see, every device connected to one of the three CS pins of a SPI host can be in single-wire or dual or quad mode.

Strange, maybe an USB hickup or a flakey solder joint somewhere. Hope it was a fluke.

Also, in case this is an issue in production, it's actually possible to program an efuse to force the ESP32 to use a certain flash voltage and ignore GPIO12.

With the new revision of the silicon, you should be able to do this. Code is very new and the new metal revision still is somewhat untested, but seems to work. We'll be manufacturing ESP-WROVER modules for this, which are similar to the ESP-WROOM32 modules but have an intergrated 4MByte of PSRAM on ...

The maximum SPI clock over GPIO is 40MHz.

'does not report anything' - you mean that the log is exactly the same before and after plugging in the board? Also, what specific devkit do you have?

If anything, the problem seems to be somewhere in the communication of the USB-serial chip and the PC, but you probably already deduced that yourself.

Are you using this in the standard esp-idf environment? In esp-idf, you could check the port_interruptNesting[xPortGetCoreID()] variable for non-zero-ness. It's defined in freertos/port.c, but not nicely exported, unfortunately. I'll think of a nicer way to get this information, it can be useful in ...

Yes, we have plans to that effect. I can't give you a timeline for that, unfortunately, though.

It seems that your host (=not the Xtensa) compiler is unhappy. Throwing that error into Google gives me a lot of people who see this problem when as on their system accidentally points to an as from a cross compiler. Can you see if that's the case?