ESP32 Forum

I have run into a brick wall with the infamous PSRAM bug again.

My firmware uses PSRAM to store fonts, which are loaded from compressed files on SPIFFS.
To reduce the firmware size, I used the miniz functions available in the ROM.

However here comes the fun part — I load the file temporarily into PSRAM, because it's too big for the main RAM. Then I unpack it into the PSRAM too, because the raw font is even bigger.

While the compiler in the toolchain knows about the PSRAM issue and works around it, I presume the ROM in the silicon was made before the bug was known, so it fails to decompress the files (I get a -3 buf error from miniz).

Adding my own `memw` before and after each call to the ROM seems to have the loading fail once, but succeed upon retry, however that is not very stable.

Is it possible to somehow update the ROM in the Rev 0 ESP32 to work around the issue in the miniz functions? I would like to avoid just importing an external miniz implementation for flash space reasons

akasaka_spk wrote: ↑

Fri Nov 15, 2024 4:04 pm

I load the file temporarily into PSRAM,

a) you may want to check alternative compression libraries which can process data in smaller chunks, like e.g. Tamp.
b) alternatively, you could look into not using a file system for some of the data but store it in a data partition where you can make sure all the data of one 'file' is stored consecutively; then you can mmap that partition and consequently read all data via a pointer directly from flash as if it were in RAM.

Is it possible to somehow update the ROM in the Rev 0 ESP32 ...

Do you really have to support Rev 0 silicon? Aren't these out of production for like 7 years by now?

Yes, I considered using a partition too, but the firmware has an OTA function for the data side of things too, and I was thinking of implementing something similar to an online catalog of fonts eventually, so the file system really makes things easier in that regard.

As for external libraries, I thought of linking in my own copy of MiniZ, but with the app partition being already at 99.7% it's a bit hard to do

And yep, I'd have assumed Rev0 to be well out of stock at this point, but in fact one of the modules I bought a couple months back had one! I guess that's why they sell them so cheap on taobao, they are so old that nobody wanted them otherwise...

Sorry, the ROM is true read-only memory... the only way to update it is to buy newer silicon. If you want to play with solutions: from what I recall (I wrote the psram workaround, but it's been years, and I try to repress those memories...) the main issue was interrupts throwing off program flow in a way that the cache didn't expect. You might be able to work around the issue by disabling interrupts before and re-enabling them after a miniz call. Not sure what other consequences that has, as miniz calls presumably are pretty long, though... if any, you may need to increase the interrupt watchdog timeout.

Thanks for the insight! Just tried that, but it seems to have actually made things worse — with a bunch of memw calls splashed here and there it decompresses fine on the second or third attempt, but without interrupts it fails altogether. I wonder if actually it needs to access somewhere in PSRAM far away from the buffer, and having interrupts enabled gives something a chance to do that? I'll try to place the memw function I made into PSRAM and see if it helps.