I am facing a similar situation where the coredump stores invalid (0xfffff) data on the flash (I can only see the crash reason stored as 3 | 14 on cpu0 and cpu1 which doesn't giveaway a lot about the resets happening) which seems impossible to read and mend. Does anyone have any idea how to deal wit...

I aim to compress and store data on a file system, with the intention of later decompressing it on the cloud side. Since Miniz employs zlib-style compression, I initially assumed that I could decompress it using any standard compressor. However, I'm currently facing challenges with this aspect.

I am facing a challenge when attempting to decompress data compressed using the miniz library on the ESP32 platform. My objective is to compress data using miniz library in flasher_stub component of esp-idf and then decompress the data on the cloud side using some python script that can be compatib...

I am facing a similar situation when attempting to decompress data compressed using the `miniz` library on the ESP32 platform. My objective is to compress data using miniz and store it on a text file and later uncompressing this text file but using python instead. As per the documentation and inform...

Hello, Is it possible to load the coredump logs into the RTC memory of the ESP32? Or maybe load the crash reason into canary byte? I know that there are attribute variables like RTC_NOINIT_ATTR/RTC_DATA_ATTR that access the RTC_SLOW_MEM (at 0x50000000) but can they log bigger strings (for example, t...