My Wio Terminal seems to be out of RAM as soon as I use WiFi. I’m using Platformio on VS Code to compile.
With just the LGFX display code running, freeMemory reports about 190,563 free bytes of memory. It’s about 2k more without the display code. But as soon as it includes WiFi functions, it drops to -25237 bytes free without connecting, and -33481 bytes free after WiFi.begin. The stack and heap seem to have already collided.
What am I doing wrong?
The libraries included in my little test program are:
Hello @dkgoodman,
I would think that LoyvanGFX and MemoryFree libraries are not compatible with Wio -Terminal.
The graphix library is already included in the Wio-Terminal standard libraries. Please have a look in the tutorials.
Best regards
RoSchmi
I think that the MemoryFree.h library cannot be used for the Wio-Terminal (at least not under PlatformIO). The symbols
//extern unsigned int __bss_end;
//extern unsigned int __heap_start;
//extern void *__brkval;
which are used in the lib seem to be not defined.
As far as I know on the Wio-Termial the address range 20000000 - 2000FFFF is used for stack (which goes downward from 200FFFF) and heap (which begins somewhere at 2000A4A0 and goes upward). When they kiss, they say good bye – to your App. To find out if you are in danger, you can fill the memory with a special pattern like AA55AA55 and look later in your program where it was overwritten.
I made some test last year, perhaps it can be helpful. Btw: I’m not an expert, perhaps there are better ways.
-https://github.com/RoSchmi/PlatformIO/tree/master/Proj/Wio_Terminal_Check_Memory_Leaks
In an application with https requests I had problems with having not enough stack. I moved some buffers into the apparently not used memory range from 20010000 - 2001FFFF. So i got it working.
I’ll give that a try. However, when compiling for the Terminal, the #ifdef tests yield this code:
return &top - reinterpret_cast<char*>(sbrk(0));
Those ARE defined, and yield seemingly good values when WiFi is not included. If that doesn’t work, we REALLY need a way to test free memory to make sure our programs operate properly.
It is strange that on your PC ‘__bss_end’, ‘__heap_start’ and *__brkval are defined and on my PC they are not.
PlatformIO gives me ‘__bss_end’ and ‘__heap_start’, each followed by 2 underscores (the forum editor makes those away) but nothing that I can associate with *__brkval. Do you know what *__brkval stands for?
On my PC the MemoryFree.h library doesn’t even compile. Where did you get it from? I used: -https://github.com/maniacbug/MemoryFree
Hello @dkgoodman
yes, I used the wrong MemoryFree library. With the library you pointed out it compiles and the code makes sense.
I did some tests here with using the rpcWifi library an without using the WiFi library and got results which I cannot interpret.
Without Wifi my test App allocates on the heap for example at address 200014C0 and the stack is used in the test at address 2002FF64.
According to my tests of last year I thought that the stack went from 2000FFFF downwards.
When I use the Wifi library (got connected successfully) data on the heap are allocated at 2000F4F0 and put on the stack at address 2000959C. So indeed the stack would be below the heap.
Actually I cannot get these findings sorted.
Maybe it automatically allocates several large buffers, for multiple simultaneous network communications, and web server operations, and crypto for secure communications? I wish the WiFi object could be constructed, and then deleted, with all its allocations released. You could go online and set time from NTP, check for messages, then free the memory. As it is, my Terminal tends to reboot, or exhibit undesired behavior when WiFi is loaded, but works well otherwise.
As already said I had to move buffers outside the normally used memory areas to get https working.
Additionally I avoided to use Strings and used char arrays instead, avoided to use debug messages and were needed used them like Serial.println(F(“Text”));
Occasionally ntp doesn’t give a response and it was needed to handle these situations gracefully.