Version 2.5.2 Portenta memory Split consecutive heap size too small

[hpssjellis]

@facchinm when we use M7:M4 core split 75:25 or 100:0 the consecutive memory in the heap is too small to load a larger machine learning model. Is this something being worked on or is it a finite limit?

See edge impulse forum discussion here it is a good read.

On the positive side I got a Grayscale OLED working with a 96x96 ML model, using the 320x240 Portenta camera using the regular M7 50:50 M4 github here

The following model simply detects other microcontrollers the LED goes blue when it "sees" a microcontroller and green when it doesn't

The only other issue is that when I try a 320x320 camera with the above ML model it also crashes even on the M7 100:0 M4. I assume it is the camera frameBuffer same consecutive heap memory issue as the above. Any suggestions for these heap issues?

[facchinm]

Hi Jeremy,
the flash split leaves the memory (RAM) map unaltered, so you won't notice any difference if you are looking for a bigger heap.
However, since the Portentat has an external 8MB RAM module (albeit slower), you could have a huge heap by just using Portenta_SDRAM library and replacing the calls to malloc and free with ea_malloc and ea_free.
Maybe it's something @janjongboom or @rajames want to investigate 😉 ?

[rajames]

Hi @facchinm thanks for the suggestion. I wasn't aware of the 8MB external memory 😛

With regards to the internal RAM. I noticed that the first 0x40000 bytes of RAM_D2 may be unused. Is that the case?

  ...
  RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
  ...
    
.lwip_sec (NOLOAD) : {
        . = ABSOLUTE(0x30040000);
        *(.RxDecripSection)
        . = ABSOLUTE(0x30040100);
        *(.TxDecripSection)
        . = ABSOLUTE(0x30040400);
        *(.RxArraySection)
        . = ABSOLUTE(0x30044000);
        *(.ethusbram)
    } >RAM_D2 AT> FLASH

I ran an example placing the application frame buffer in that area and it worked fine.

If it's unusued, is it possible to give this area to the application heap? Moreover is there away to use the entire RAM_D2 segment in the case when no connectivity (emac) is required?

[facchinm]

@rajames you can use the RAM sections as you prefer as long as you know what you are doing 🙂

Eg. M4 uses RAM_D2 as its only memory, so if you are running a sketch on M4 the same memory can't be used by the M7 .
Same for EMAC: if you are not using the Ethernet library, that area is safe, otherwise you'd encounter awful memory corruption bugs.

On our side, we want to keep the "safe" zone as broad as possible, so it's very difficult for the end user to shoot himself in the foot. Any other "dangerous" tuning is to be considered unsupported 😉

[rajames]

@facchinm thanks for the explanation, it helps.

Is there away to not link the Ethernet Library (buffers) at compile/link time so that RAM_D2 can be completely used at compile/link time?

[hpssjellis]

Linked to Issue 38 SDRAM examples