Heap size on nano 33 BLE? (64K when I expected >128K)

bmcm · November 17, 2022, 12:16pm

This is not a show stopper for me (yet!) but I have just been checking the available heap memory on the arduino nano33 ble port:

import gc

free = gc.mem_free()
alloc = gc.mem_alloc()
total = free+alloc

print("free: {:d} alloc: {:d} total: {:d}".format(free, alloc, total))

yielding (with the latest dev firmware):

free: 62352 alloc: 1664 total: 64016
MPY: soft reboot
OpenMV 8e27bd7; MicroPython f72d922; Arduino Nano 33 BLE SENSE-NRF52840
Type "help()" for more information.
>>>

The nano33 BLE NRF52840 docs say it has 256K on board. Further I think the nano33 port uses this specific linker script nrf52840_1M_256k.ld containing the following:

_flash_size = 1M;
_ram_size   = 256K;

/* produce a link error if there is not this amount of RAM for these sections */
_stack_size = 8K;
_minimum_heap_size = 128K;

which certainly seems to indicate that the heap should be at least 128K.

Just wondering if anyone can shed any additional light on this discrepancy?

Many thanks - Barry

kwagyeman · November 17, 2022, 2:58pm

We have to allocate space for a frame buffer since Arduino wanted us to support a camera. This is a fixed allocation.

github.com

openmv/openmv/blob/master/src/omv/boards/NANO33/omv_boardconfig.h#L84


      
          #define OMV_CORE_VBAT           "3.3"
          
          
// USB IRQn.
          #define OMV_USB_IRQN            (USBD_IRQn)
          
          
// Linker script constants (see the linker script template port/x.ld.S).
          #define OMV_FB_MEMORY           SRAM    // Framebuffer, fb_alloc
          #define OMV_MAIN_MEMORY         SRAM    // data, bss and heap memory
          #define OMV_STACK_MEMORY        SRAM    // stack memory
          
          
#define OMV_FB_SIZE             (128K)  // FB memory: header + QVGA/GS image
          #define OMV_FB_ALLOC_SIZE       (16K)   // minimum fb alloc size
          #define OMV_STACK_SIZE          (8K)
          #define OMV_HEAP_SIZE           (64K)
          #define OMV_JPEG_BUF_SIZE       (16 * 1024) // IDE JPEG buffer (header + data).
          
          
#define OMV_TEXT_ORIGIN         0x00026000
          #define OMV_FFS_LENGTH          64K
          #define OMV_TEXT_LENGTH         680K        // 0x00000 -> 0x26000  Soft device (152K)
                                                      // 0x26000 -> 0xD0000  OpenMV firmware (680K).
                                                      // 0xD0000 -> 0xE0000  Flash filesystem (64K).

bmcm · November 18, 2022, 5:16pm

OK great, thanks for the clarification.

Presumably that means that in applications not using a camera, it would be possible (in principle at least) to configure this frame buffer back to use as general heap space? I’m guessing that can only be done by rebuilding (a fork of) the full firmware distribution (as opposed to be able to dynamically tweak it in any way with the distributed firmware)? Assuming that to be so, would the mod to the source be as minor as tweaking the #defines in the omv_boardconfig.h file or are changes there likely to require more pervasive modifications elsewhere?

(I don’t quite need to roll up my sleeves to attempt this yet, but I can see it as being a definite possibility in the near future, so any pointers will be appreciated…)

iabdalkader · November 19, 2022, 5:42pm

Yes it’s possible to increase the heap memory by reducing FB size OMV_FB_SIZE and increasing the OMV_HEAP_SIZE

bmcm · November 23, 2022, 4:39pm

Great - thanks for that clarification.

kwagyeman · November 24, 2022, 7:45pm

So, we actually have an automated build system via github actions. You just need to fork our repo, enable github actions, then modify the file above and your new firmware will be automatically built.