I don't think that is a size issue. The issue seems more that you/your code seems to use dynamic allocation (malloc() and friends) and I don't think this is available in the bootloader.

micronpn wrote: ↑

Thu Apr 25, 2024 2:50 pm

without using FreeRTOS and Arduino framework.

Doubt that exists. FreeRTOS is the thing already running as a RTOS on ESP-IDF (because without a RTOS you can't really run BT/WiFi), so why not use that?

I'm decently sure #3 is the level 4 interrupt handler entry, I don't think that is suspect. From the line it calls the panic handler from, it seems that the interrupt watchdog timed out hard. You're not using anything that can get you into a loop in a critical section?

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.

Edit: We think some database wrangling fixed the issue. We'll be monitoring for now.

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.