-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPIRAM corruption in light sleep mode (IDFGH-10297) #11558
Comments
I think we had a similar issue before, and I think enabling the
See: |
Hi, thanks for the information. Then I will keep Which PSRAM chip is included in the |
@huming2207 Thanks for your explanation, it's absolutely correct. @Erlkoenig90, the CS pin is not pulled up in the chip package, and it not mapped out to the module pin, so if you are using modules, you must enable this option (maybe we should emphasize this in the help doc). Compared with adding a pull-up resistor outside the chip, this software solution only increases the current by a few uA, which is acceptable for lightsleep. |
Answers checklist.
IDF version.
both v5.0.2 and master/903af13e847cd301e476d8b16b4ee1c21b30b5c6
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-S3-DevKitC
Power Supply used.
USB
What is the expected behavior?
When using sleep mode, SPIRAM contents should stay intact.
What is the actual behavior?
When the CPU is in light-sleep for > ~10min, individual bits in SPIRAM are flipped. If data structures / pointers are affected, this leads to random crashes/errors.
Steps to reproduce.
This error occurs when memory in SPIRAM is allocated via
heap_caps_malloc (bufSize, MALLOC_CAP_SPIRAM)
, some data is written to memory, sleep mode is entered for some time (10s to 10min), and then memory is read again. Some of the read bytes have one bit flipped.The following config options are set to reproduce this:
ESPTOOLPY_FLASHSIZE_8MB
SPIRAM
SPIRAM_MODE_OCT
SPIRAM_USE_CAPS_ALLOC
PM_ENABLE
FREERTOS_USE_TICKLESS_IDLE
ESP_DEFAULT_CPU_FREQ_MHZ_240
COMPILER_OPTIMIZATION_PERF
However, when
ESP_SLEEP_PSRAM_LEAKAGE_WORKAROUND
andESP_SLEEP_FLASH_LEAKAGE_WORKAROUND
are set, this issue does not occur.Debug Logs.
More Information.
It took me a long time to narrow this issue down. I experienced random crashes in a complex application after waking up from sleep mode which turned out to be caused by the memory corruption. I accidentally disabled
ESP_SLEEP_PSRAM_LEAKAGE_WORKAROUND
andESP_SLEEP_FLASH_LEAKAGE_WORKAROUND
. I didn't realize that those are necessary to use SPIRAM and sleep mode. The documentation for those settings states that they can be used to reduce power consumption in sleep mode, but not that they are needed to keep SPIRAM data valid.I am not sure whether this is normal/intended behavior. Should SPIRAM work normally even without
ESP_SLEEP_PSRAM_LEAKAGE_WORKAROUND
andESP_SLEEP_FLASH_LEAKAGE_WORKAROUND
, just with higher power consumption?Perhaps this is just a documentation issue? Should the documentation for those config settings state that they are necessary for using sleep mode? Maybe the doc for SPIRAM and sleep modes should have a warning that those settings are needed?
Would it make sense to run a memory check after waking up from sleep mode to verify SPIRAM contents is still valid (keeping a checksum in IRAM)?
The text was updated successfully, but these errors were encountered: