rashedtalukder
commented
2 years ago Have you set an increased LV_MEM_SIZE?
Open pmumby opened 2 years ago
rashedtalukder
commented
2 years ago Have you set an increased LV_MEM_SIZE?
pmumby
commented
2 years ago Have you set an increased
LV_MEM_SIZE?
Hi Rashed, I have not changed LV_MEM_SIZE from what is set as default in this library (32kb).
Is that size being used for the DMA buffers for SPI though?
If you look in the stack trace of the error, you can see the allocation failure is specifically happening in the code for allocating SPI buffers for the SPI connected display, which require DMA capability.
Obviously DMA is the most constrained memory, but the code runs fine for anywhere from 30min to several hours, with UI working perfectly, then fails (at somewhat random intervals). During this time monitoring heap usage and fragmentation shows that we have between 20kb and 35kb of free DMA memory depending on the circumstances. So if the issue were allocation of 32kb block of DMA memory one would think it would be throwing the error immediately, or at least far more commonly.
For example here is a dump of heap telemetry we are sending from the device. This was taken from a running device that had been online for nearly 1 hour, on which the UI had not yet locked up (it had not yet thrown the allocation exception):
"heap": {
"internal": {
"allocatedBlocks": 428,
"totalFreeBytes": 40027,
"minimumFreeBytes": 16199,
"largestFreeBlock": 19456,
"freeBlocks": 17,
"totalBlocks": 445
"freeBlocks": 16,
"totalBlocks": 444
},
"dram": {
"allocatedBlocks": 553,
"totalFreeBytes": 3614854,
"minimumFreeBytes": 3566798,
"largestFreeBlock": 3538944,
"freeBlocks": 25,
"totalBlocks": 578
"freeBlocks": 24,
"totalBlocks": 577
},
"iram": {
"allocatedBlocks": 0,
"totalFreeBytes": 0,
"minimumFreeBytes": 0,
"largestFreeBlock": 0,
"freeBlocks": 0,
"totalBlocks": 0
},
"dma": {
"allocatedBlocks": 428,
"totalFreeBytes": 38435,
"minimumFreeBytes": 14623,
"largestFreeBlock": 19456,
"freeBlocks": 16,
"totalBlocks": 444
"freeBlocks": 15,
"totalBlocks": 443
},
"spiram": {
"allocatedBlocks": 125,
"totalFreeBytes": 3576419,
"minimumFreeBytes": 3552175,
"largestFreeBlock": 3538944,
"freeBlocks": 9,
"totalBlocks": 134
}
},
Summary:
We are experiencing a memory allocation failure in the LVGL library when trying to allocate DMA enabled heap for SPI use. Under normal circumstances this error is non-fatal (without customizing the build config so that it throws a fatal error). The end result is that the UI task hangs, and our UI and touchscreen become completely locked up (all other functions of the device continue without interruption).
Background:
We are implementing this component as a hardware abstraction library for our use of the M5Stack Core2 for an IoT Product. To that end, we've forked this repo to: https://github.com/Flow-Coffee-Limited/Core2-for-AWS-IoT-EduKit
In order to integrate the component into our ESP-IDF 4.4 project, we've created a branch which is pinned to the same commit hash as the template project at: https://github.com/aws-iot-edukit/Project_Template-Core2_for_AWS this branch we've called
flow_fgv3_activeWe are building using ESP_IDF 4.4 as I mentioned above. We have a dockerized build environment that pre-installs IDF and prerequisites into a docker container, then we use scripts to run the build within the container.
We were on ESP_IDF 4.2, and running older AWS MQTT lib, and older Core2 for AWS lib, unfortunately we had another problem with the MQTT stack which required us to update the MQTT library, which in turn required upgrading to IDF 4.4, and subsequently required upgrading to the BSP_Dev branch of Core2 for AWS lib.
It should be noted that we did not encounter this bug on the previous version of the Core2 for AWS lib, however that was an older version and not the refactored BSP_Dev branch, additionally much else has changed with roll to IDF 4.4, and new MQTT lib, so hardly a clean test, unfortunately these components can't easily be swapped in isolation.
Docker Build Container:
The Docker file builds ESP_IDF branch
release/v4.4and installs all other prerequisites on a base of ubuntu:22.04 (dockerfile attached) esp_idf_dockerfile.zip And here is an example of how to use said docker file:docker run -it -v $(pwd):"/project" esp-idf-build-container $(id -u) $(id -g) /bin/bashWhich will provide a bash console inside the container, mounting the current working directory into the /project volume in the container (assuming your current working directory is the root of an IDF project). Alternatively you could substitute/bin/bashfor an idf command such asidf.py buildsince the idf environment is automatically sourced inside the build container.Stack Trace of the error we're seeing:
(note paths have been sanitized, but everything else is intact)
What have we tried so far?
We have tried the following to troubleshoot/resolve the issue:
Happy to provide any further info as needed.
Any assistance would be greatly appreciated.