out of memory error

Recurrent H/W and software problems
Post Reply
Stuart
Posts: 126
Joined: Fri Feb 19, 2021 7:46 pm
Has thanked: 5 times
Been thanked: 20 times

out of memory error

Post by Stuart »

I have a 32bit system that cycles round every few seconds, monitoring my central heating and controlling the water temperature. It works well normally. But I'm getting out of memory errors. The normal ramfree reading is consistently around 84k. There is no obvious provocation, and the reported location varies and does not offer any clues. Does anyone have any diagnostic tool that might help me find where the problem is?

Alternatively is there any good practice that minimises ram usage that I could try? e.g. are SUBs better than GOSUBs? Computed GOSUBs better than SELECT?

I'm currently using Annex32 WiFi BLE CAN 1.44.2.

Any ideas welcome, as this needs to be rock solid 24 x 7 and it isn't!

Stuart
User avatar
cicciocb
Site Admin
Posts: 1889
Joined: Mon Feb 03, 2020 1:15 pm
Location: Toulouse
Has thanked: 405 times
Been thanked: 1260 times
Contact:

Re: out of memory error

Post by cicciocb »

From my point of view, you are probably doing some memory intensive activity in background, such as an https:// request.
The https: requires a lot of memory and could cause this problem.

The first approach :
- If you do not need the BLE, install the version without BLE as this gives more ram free

The second approach :
- Use a module with PSRAM
User avatar
Electroguard
Posts: 835
Joined: Mon Feb 08, 2021 6:22 pm
Has thanked: 267 times
Been thanked: 317 times

Re: out of memory error

Post by Electroguard »

As CiccioCB says, some things can cause sudden extra high memory demands, and it's not easy to know what when and where caused the actual problem.

So if I can't find the the actual cause or the absolute value of ramfree during the problem, I monitor the relative ramfree.
At the top of my script (above WAIT) I declare a mem comparison variable plus a memory threshold var, then periodically monitor ramfree to log its time-stamped value each time it reduces.
This will display a record of all ramfree reductions and when they occured, which may help relate to a particular event causing the problems.
But at the very least it will show what the last ramfree was that still worked ok prior to the problem, allowing you to add a generous safety margin and set that as the minimum acceptable memory threshold.
Once you have that minmem allowable threshold level prior to the problem, you can take whatever avoiding actions you choose, such as reboot and autorun, or perhaps branch to dump out variable values to look for a smoking gun before it kills the device.

mem = ramfree
minmem = xxxxx
timer1 1000, heartbeat
wait

heartbeat:
if ramfree < mem then mem=ramfree: wlog str$(mem) + " at " + time$ + " on " + date$
if mem < minmem then gosub listvars
'or reboot
Post Reply