Closed
Description
Hi @PaulZC,
As discussed earlier, we'll need to fix how the .createFileBuffer()
function allocates RAM. At present, if the system makes multiple calls to .begin()
, RAM usage will eventually exceed the available memory (e.g. a 16 KB file buffer will consume all 384 KB RAM on the Artemis after 24 sleep/wake cycles). In actuality, this seems to occur at about the 14th sleep/wake cycle, which causes an immediate hard reset of the processor.
Offending line of code:
Cheers,
Adam
Metadata
Metadata
Assignees
Labels
No labels
Activity
Correct #20. Add .end. Add getFileBufferSize. Add Example26
PaulZC commentedon Apr 1, 2021
Thanks for finding this Adam!
Corrected in this commit.
Please give Example26 a try.
adamgarbo commentedon Apr 1, 2021
Thanks, Paul!
Will try it out this morning. Can you clarify what you mean by "End will stop all automatic message processing and free (nearly) all used RAM."? Is there still some RAM that will be lost after each
.begin()
call? Thinking about long-term (1-year) deployments of the code.Cheers,
Adam
PaulZC commentedon Apr 1, 2021
Hi Adam,
The memory leak - from multiple calls to .begin - should be completely fixed.
.end is optional but you can use it to deallocate (delete) all of the allocated RAM except payloadCfg. (That's why I use the word "nearly"!).
Cheers,
Paul
adamgarbo commentedon Apr 1, 2021
Thanks, Paul!
I've been letting the code run all morning and am currently up to 40 sleep/wake cycles with a 16 KB buffer and no issues!
Cheers,
Adam
PaulZC commentedon Apr 1, 2021
Jolly good!
Have a nice Easter!
:-)