Free memory on Wio Terminal using WiFi

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:

seeed-studio/Seeed Arduino rpcWiFi@^1.0.5
seeed-studio/Seeed Arduino rpcUnified@^2.1.3
seeed-studio/Seeed Arduino FS@^2.1.1|

Here’s the code…

#include <Arduino.h>
#include <rpcWiFi.h>
#include “LovyanGFX.h”
#include “MemoryFree.h”

#define SSID “change”
#define PASSWORD “change”

#define USE_WIFI

LGFX display;

void setup_display() {
display.setTextColor( TFT_WHITE );
display.setFont( &FreeSans9pt7b );
display.drawString( F(“Started up”), 0, 0 );

void setup() {
Serial.println(“Tester started.”);

Serial.println("Memory before LGFX: " + String(freeMemory()) );
Serial.println("Memory after LGFX: " + String(freeMemory()) );

#ifdef USE_WIFI
Serial.println("Memory before WiFi: " + String(freeMemory()) );
Serial.println("Memory after WiFi: " + String(freeMemory()) );


void loop() {

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

Thank you for your response.

I uninstalled LovyanGFX and installed Seeed_Arduino_LCD instead. Still have the same issue:

Tester started.
Memory before TFT: -25217
Memory after TFT: -25269
Memory before WiFi: -25269
Memory after WiFi: -33477

Just in case it was a PlatformIO issue, I tried following the installation instructions for using the Arduino IDE (shudder). Result…

Tester started.
Memory before TFT: -25221
Memory after TFT: -25273
Memory before WiFi: -25273
Memory after WiFi: -33517

Is WiFi not viable on a Wio Terminal?

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.
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: -

I got it from and commented out the pgmStrToRAM stuff. Try this:

int freeMemory() {
char top;

return &top - reinterpret_cast<char*>(sbrk(0));

Using the address of top gives us the address of the stack, and asking sbrk for 0 memory gives us the address of the heap.

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.

Hi @dkgoodman ,
dispite not really understanding how stack and heap are handeled, my example App which uses https basically still works but has occasional hangs.
-Wio Terminal App Sending Sensor Data to Azure Storage Tables -
Occasinal hangs were repeatedly reported for WiFi use with Wio-Terminal.

-Wio Terminal App (rpcWiFi lib) sending telemetry data to Azure Storage Tables stops working after many uploads

-rpcWifi problem when wifi is lost

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.