As you may have noticed, ESP32.com has been somewhat unstable recently. We're looking into this and will have this fixed as soon as we're able. Our apologies for the inconvenience.

Not sure exactly where, but I'm pretty sure it's a menuconfig option.

Pin 12 is a bootstrap pin that sets the flash voltage; your GSM module is probably pulling that to the wrong level. You can either move that pin or use espefuse.py to force vdd_sio to 3.3V

ESP-IDF should give you a backtrace for that crash; if you run 'idf.py monitor' as your terminal it should automatically be decoded into something readable. What does that say? Also, the PC in the crash is '%u _' in ascii, so whatever function pointer you're overwriting, it seems to be overwritten w...

That is because, according to the docs you provided, MEM_DATA loads data to RAM, not flash. Btw, we have existing flashing code in C, if that's what you need.

Anything connected to GPIO12? In general, what pins is the GSM module connected to?

You're only flashing the application code. If your ESP32C6 flash is entirely erased, you'll also need to flash the bootloader and partition table.

Also one more instant question, is there any document describing register policy in ISR? For example what registers are automaticaly preserved and how, what registers can be changed and what registers must not be changed and so on. Are there some registers strictly reserved by ESP-IDF. I mean, for ...

That's an issue between the USB-serial chip and your PC, the ESP32 doesn't have anything to do with this and 'factory resetting' won't solve your problem. I don't know enough about Windows drivers to say more; perhaps you need to reinstall the driver or something?

I think that's all part of the lower level MAC/PHY code, and we haven't open-sourced or publicly documented that.