Thoughts on using FLASH memory instead of DRAM for static security data on ESP chips?

I tried the flash-moving idea last month when I was setting up a bunch of sensors for a monitoring project. My old setup was using the standard libraries and it crashed after about three days because of memory fragmentation, even though the total size seemed okay at first glance. Moving the EAP credentials and the certificate chain into the external flash helped initially, but the performance hit was noticible. I was running a simple ping every minute, and the latency spiked significantly after about 15 minutes of operation. The chip was working hard to constantly swap data over the SPI bus just to find a private key for the TLS negotiation. I found that the bottleneck wasn't the total amount of RAM consumed during the handshake itself, but rather the garbage collection that happened afterward because the heap was so mangled by those constant writes. If you are doing this kind of stuff, you need to manage the heap much more carefully. I ended up dedicating a fixed-size buffer early on for the TLS stack instead of letting the library dynamically allocate everythign it needed. It was a bit of a pain to modify the source code, but it kept the memory predictable and stable over time. It took some trial and error with those buffer sizes, though.

I found that moving the certificates to flash wasn't the only way to stabilize things when I was setting up a mesh network last summer. I ran into a similar issue with the corporate network because the required memory allocation for the initial connection was just too high for my paticular setup. Instead of shifting the entire credential set out of RAM, my approach was much more focused on tightening the software itself.

I spent a good few days digging into the low-level settings for the TLS packet handling buffers. By reducing the size of those intermediate buffers by about thirty percent, I managed to keep the heap usage much lower right at the point of the EAP handshake. It seemed like the library was just hoarding memory during the initial exchange, and adjusting the allocated buffer sizes made the whole thing run much more smoothly without needing to mess with flash mapping.

It wasn't a perfect fix for every device, but for my particular sensor project where I was using a limited amount of power, this software tweak actually kept the device stable for months without having to deal with constant reboots or memory fragmentation. It was definitely less invasive than writing code to handle large static data storage in the external chip.

I had a rough run with this exact thing back in the day on an even older platform. Moving data to flash is a fix for size, but it doesn't solve the problem of the chip trying to use too many resources while looking it up. You have to look at the low level, specifically the network interface stack footprint. Did you try tightening the stack configuration itself instead of just stuffing credentials into a seprate file? Back then we often had to use raw socket methods just to keep the memory usage predictable.

Considering the latency introduced by external SPI access for certificate retrieval, one must also seriously consider the computational overhead of the decompression routine itself once the raw blob is transferred into the internal RAM buffers, even if the bulk data is technically residing in flash memory. Furthermore, if the EAP identity or associated credentials are subject to frequent rotation or changing across different access points, the performance penalty of reloading those necessary cryptographic primitives from storage becomes significantly more pronounced during every subsequent connection attempt.

I noticed that even if you manage to shove all the crypto data into flash, the way you pull that data into RAM still determines how smooth the handshake runs. Reading the whole cert in one go is usally inefficient for the bus. In my previous role, I determined that chunking the EAP identity and credentials into buffers no larger than 256 bytes significantly smoothed out the startup time. This granular approach cut the required load time by about 40 percent compared to a single large buffer request. The bus stays much less stressed that way.

Update: I went with the approach of moving the large blobs of cert data into flash memory. I was worried about the speed hit from that external SPI access, but the performance was better than the frequent crashes. My heap issues are resolved now. It took some fiddling with the read routine to get it running smoothly.