I usually use espcoredump.py (from $IDF_PATH/components/espcoredump/espcoredump.py) for decoding a coredump that I've read from flash. You'll need to have the .efl (not the .bin that you flash to the device, but the .elf that gets built the same time as the .bin) of the firmware that was flashed to ...

Not a problem. That is just the IDF monitor letting you know that the checksum of the firmware running on your ESP32 doesn't match the checksum of the built firmware on the machine that you're running IDF monitor from. See here. The message isn't coming from your ESP device, but rather IDF monitor.

The ESP IDF source has an example for MQTT with mutual authentication that shows how to embed certificates in code along with the changes that need to be made in CMakeLists.txt.

I'm working on a project that is similar to what you're describing, although I'm letting AWS be the CA rather than use a different CA and a CSR. In my case I'm using the standard IDF MQTT client without the AWS IoT SDK.

On the ESP side I used the web server component to expose a post endpoint that ...

In the process of creating the reproducer test code I figured out what is causing the panic (that's how it usually goes, right?). I'm not sure if it is really a bug as much as a change in behavior, but the crux of it is this: If you enable a UART pattern detect interrupt on some UART port, AND also ...

Hi ESP_Sprite,

I really can't post the entire project code, but I will try and create a simple reproducer for the issue.

It really is a strange bug... As far as UARTs go, my code isn't doing anything special. UART0 is just the normal serial console for downloads and logs, and I use UART1 for a ...

I'm working on upgrading my code from IDF 5.1.2 to 5.2.1 and am seeing a crash when the code enters deep sleep. Here's the crash:


I (11614) cl_main: Deep sleep for 289277 millis
Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0).

Core 0 register dump:
PC : 0x4008206b PS ...

By chance are you using IO16 as one of your SPI pins? According to the data sheet (page 24, figure 7):

In module variants that have embedded QSPI PSRAM, i.e., that embed ESP32-D0WDR2-V3, IO16 should be pulled-up and can not be used for other funtion

You might try adding a call to adc1_ulp_enable() before re-entering deep sleep after you've done your HTTP upload. I noticed something similar recently where I had a ULP program reading ADC values, and occasionally waking to upload the values to via MQTT. Simply connecting to wifi was enough to have ...