Reduce RAM overhead and free ~9kB of memory

[JF002]

Using SystemMonitor, I checked the memory usage of the global heap, the FreeRTOS heap, the LVGL heap and the stack of the task.

Here are the results on develop (e0013e7):

Memory region         Used Size  Region Size  %age Used
           FLASH:      412136 B       480 KB     83.85%
             RAM:       57520 B        64 KB     87.77%

Free heap : 624
<info> app: Task [IDL] - 43
<info> app: Task [MAI] - 94
<info> app: Task [dis] - 308
<info> app: Task [LOG] - 71
<info> app: Task [Tmr] - 209
<info> app: Task [Hea] - 411
<info> app: Task [ble] - 491
<info> app: Task [ll] - 246
<info> app: #LVGL Memory#
 used# 6504 (46%) / free 7832
 max used# 6820
 frag# 1%
 free# 7820
<info> app: heap : 2740

• Free heap (first line) is the memory available on the FreeRTOS heap
• Task[xxx] shows the minimum space available in the stack of the task (watermacked value).
• LVGL max used is also a watermacked value of the maximum memory used by LVGL
• heap (last line) is the space available in the global heap (malloc).

This PR reduces the following buffers:

• Global heap : from 4kB to 3kB (-1024B)
• FreeRTOS heap : from 17kB to 14kB (-3072B)
• LVGL heap : from 14kB to 8kB (-6144B)

And the following stacks:

• Timer task stack : from 1200B to 1000B (200B)
• Display task stack : from 3200B to 2400B (-800B)
• BLE ll task stack : from 1280B to 560B (-720B)
• BLE host task stack : from 2880B to 1320B (-1560B)
• System task stack : from 1400B to 1200B (-200B)

In total, this PR frees 10507B of RAM memory, which is quite nice! This memory has always been available, but it was over-allocated in those buffers. Reducing the size of the buffers according to the needs of the current code allows us to have a better overview of the memory currently available.

Memory region         Used Size  Region Size  %age Used
           FLASH:      412056 B       480 KB     83.83%
             RAM:       48304 B        64 KB     73.71%

Free heap : 1032
<info> app: Task [MAI] - 44
<info> app: Task [IDL] - 43
<info> app: Task [Hea] - 425
<info> app: Task [LOG] - 71
<info> app: Task [Tmr] - 159
<info> app: Task [dis] - 111
<info> app: Task [ll] - 69
<info> app: Task [ble] - 103
<info> app: #LVGL Memory#
 used# 6484 (80%) / free 1708
 max used# 6800
 frag# 1%
 free# 1696
<info> app: heap : 2740

How to test this PR ?

You can build this branch with RTT logging enabled to check the logs from the System Monitor.

Most of those info are also available in the SystemMonitor app in InfiniTime. What should you check?

• Free heap should not decrease under 0
• Task stack should not decrease under 0
• LVGL max used should no overflow 8192
• Global heap should not overflow 3072

Example on my sealed PineTime running for ~10hours:

[JF002]

This version has just crashed on my PineTime just after secure pairing with my phone. Maybe a buffer is a bit too tight? I'll debug this asap!

[evergreen22]

Don't forget that I already adjusted the BLE and LL stack sizes in #796 (1.8.0).

[kieranc]

This version has just crashed on my PineTime just after secure pairing with my phone. Maybe a buffer is a bit too tight? I'll debug this asap!

I just found the same thing.

[kieranc]

I just tried building this with the BLE/LL stack sizes as before (600/200) and the watch resets during boot before getting to the watchface. I had a second try setting the BLE/LL back to 210/20 and FreeRTOS heap to 15 rather than 14, the watch boots correctly but secure pairing still causes a reboot. Third try with FreeRTOS 15, BLE/LL 600/200 still doesn't boot. As ever I don't really know what I'm doing but maybe this info will be useful :shrug:

[JF002]

Thanks for those tests :) I haven't had the opportunity to analyze those issues deeper, but I have probably overlooked something... As @evergreen22 said, the stack of BLE tasks were increased for secure pairing, and I reduce them in this PR, which is probably wrong...

[kieranc]

I figured the same, but putting them back to their previous values makes it not boot. I assumed some other 'container' in which they reside needed to be increased to make room, I figured it'd be the FreeRTOS heap but apparently not? I'll keep fiddling! Also interesting is it's only new secure pairings which cause a reboot, it will reconnect to an existing bond with this PR no problem.

[trman]

any news @JF002 , is this still crashing ?

[JF002]

I haven't taken the time to check out these changes yet. I think I was a little too aggressive with the stack size reduction.