DMAMEM? MEM2?

B

Bewing

Member
I'm working on Teensy 4.0 with LVGL / ili9488 / Arduino. My app looks great in the LVGL simulator but crashes ("out of memory") instantly on the T4. (I'm SO grateful that it is able to tell me!) If I remove a few visual objects, it runs for a while (in some configurations re-booting every 10 seconds), and stable if I remove enough (see "Note" at end). Optimizing "Smallest Code with LTO" helps. There's a lot I still need to add (real-time audio); I'm distressed to already have memory issues. Speed is NOT an issue. Adding "DMAMEM" produces errors as follows:

R:\QTRNM-QFSV\Teensy\Quartetronome\menui.cpp:59:11: error: expected initializer before 'DMAMEM'
59 | int Test1 DMAMEM;
| ^~~~~~
R:\QTRNM-QFSV\Teensy\Quartetronome\menui.cpp:60:12: error: expected initializer before 'Test2'
60 | int DMAMEM Test2;
| ^~~~~
R:\QTRNM-QFSV\Teensy\Quartetronome\menui.cpp:61:2: error: 'DMAMEM' does not name a type
61 | DMAMEM int Test3;
| ^~~~~~
I'm not comfortable publishing all my (proprietary) code. One user here complained that Arduino lost Teensyduino -- no such problem here. Is there something I need to #include? Do I need to learn how to make a linker file? How can I move stuff into MEM2? Thanks for any help. --BE
Note: when it's "on the edge" (enough objects removed to be stable), moving a slider or pressing a button can cause a crash. I don't really understand why that would be -- the objects are all created before the callbacks are called, and no new objects are created in the callbacks. Why does the callback crash it?
 
The definition of DMAMEM is in avr/pgmspace.h. So try adding this at the top of your source file
Code: 
#include <avr/pgmspace.h>
 
Bewing said:
Why does the callback crash it?
Click to expand...
Perhaps the callbacks need more STACK space than you have available. Post the memory information generated after the build so we can look to see just how close to the edge you actually are.
 
Thanks -- that's a BIGG help! Now, how did you know that (and how did I miss it?) So, turning everything on and not moving anything to RAM2 (except my 3 test int's -- turns out you can put DMAMEM anywhere on the line), I get:
Memory Usage on Teensy 4.0:
FLASH: code:203472, data:69568, headers:8556 free for files:1750020
RAM1: variables:152128, code:201624, padding:27752 free for local variables:142784
RAM2: variables:12416 free for malloc/new:511872
I have an infantile understanding, but I don't understand how the callbacks -- which just change button colors and slider values -- would use much stack space. Thanks again for this quick and incredibly useful, targeted help!
 
That looks like you have loads of free memory available to begin with, which means the out-of-memory issues are most likely caused by trying to allocate too much dynamic memory (using malloc() or new). Moving objects into RAM2 isn't going to help with that, in fact it will make it worse since all dynamic allocations always come out of RAM2.
 
Have you tried to increase LV_MEM_SIZE from the default 64k, to say 128k in lv_conf?

Can you confirm as well that you don’t have a memory leak in your lvgl app? Is lv mem monitor enabled in the simulator? Is it enabled on your T4 build?
 
Check this thread and this post. I had the same problem and added the FLASHMEM attribute to all LVGL code. Definitely not a good way to do it.

What looks strange to me, LVGL is succesfully used on ESP-32 which has less RAM. Is the code executed only in flash on the ESP-32 ???
 
Rezo WINS!!! I changed LV_MEM_SIZE from (32U * 1024U) ... to ... (128U * 1024U) -- (why the "U"s?) and everything works and is solid as a rock!! (I see the simulator uses (256 * 1024U) -- (no first U?) (I'm clueless about lv mem monitor...)
Thanks, My day ends in rare peace, I'm so happy about the support and AMAZED to get LVGL help here at pjrc (and I would happily make my (actually, SKPang's updated) LVGL driver port public domain except I'm slightly Git-averse.) I'm also extremely grateful for the tips from defragster and Angelo -- clearly useful stuff I'll use later. I wonder what else I should know about. I have generally treated LVGL as a (sweet) "black box"...
 
U’s are for Unsigned, its a suffix to tell the compiler that the value is a constant unsigned int.

I still urge to use the lv memory monitor.
I used it to identify a memory leak a few years back that happened each time I navigated between screens.
 
You must log in or register to reply here.
Back
Top