This is very relevant to Edge Impulse as the camera now has 320x320 resolution and the IDE can split the memory in 3 ways between the cores 50:50, 75:25, 100:0 (With zero memory for the M4 core it needs to load from the SD Card on the vision shields or the breakout board.)
Does anyone know the code to show the Edge Impulse relevant memory information. I am trying to load a model that will not run on the regular M7 core 50:50 memory, but will run for the M7 if we switch to 75:25 memory.
Was thinking some statement like this, would at least say how big my vision frame buffer is.
@janjongboom@dansitu I am getting tFlite memory Arena issues when using the expanded Portenta memory from ~1Mb to 2Mb. Is it possible for Arduino the TFLITE Arena is set in EdgeImpulse code and not flexible. Can someone show me where to see the code that sets the model size. I know where it is done using TensorflowLite, just not using Edge Impulse.
…
3 minutes later!
… Not sure why I have to post a question on the Forum before I think of a way to solve the issue
In the file trained_model_compiled.cpp
There is this Variable, Where does that max file size come from? I will probably play around with changing it, but is this something Edge Impulse can do based on if the Arduino has ore memory? Or is this not the issue?
constexpr int kTensorArenaSize = 286432;
… few minutes later
So this is what I am seeing, using a model that is slightly bigger than what will fit on the regular M7 core.
Trying to figure out if this is an Arduino issue or an edge impulse issue. Looks like the software is not allocating the Arena, which might be an Arduino issue. Anyone got any suggestions?
.
Actually the above issue might be more to do with me trying the camera at 320x320, so I am testing again but using the regular 320x240 camera setting.
@Rocksetta this number is calculated by EON Compiler and has all allocations that need to be made by the TFLite kernels. I’m not sure how the memory is managed on the Portenta but:
Not sure if everything is in one bank, or how the memory is split up. You can set EI_CLASSIFIER_ALLOCATION_STATIC to allocate statically (not on the heap) and then you have freedom to put this into separate section of RAM.
Thanks @janjongboom trying that now. I know in the vision code we set the uint8_t frame_buffer[320*240] __attribute__((aligned(32))); not sure if that is at all relevant.
Here is the trained_model_compiled.cpp file relevant parts, what are the other options
You can use the mbed url that @janjongboom linked to get memory information just before classification. The core has it enabled so following the steps in the URL and adding the print_memory_info() could prove useful debugging this.
I’ve been dabbing around with core 2.5.2 as well and ran into similar issue with not enough RAM. I’ve managed using MobileNetV1 0.25 which produces model of 108.5 kB (in my case) which allowed me to allocate enough to run an impulse. In my case this was my output and rationale for selecting a model size:
Thanks @janjongboom and @rjames for the example print_memory_info(); Not sure about the map file.
If anyone can word the issue intelligently, can you put it on the Arduino coreMbed github https://github.com/arduino/ArduinoCore-mbed/issues
make sure to add me @hpssjellis and @facchinm as he seems to be the lead with these issues. If you want to describe it here I will put in the issue.
I think I will work on something else but this is what I got today:
M7 core working with 50:50 memory Split small vision model
The heap is placed in the 512 KB (RAM) segment. It is important to note that
the flash split option does not affect the heap size. The heap size is thus
determined by the amount of (static) RAM used.
With regards to map file you can find it (on Linux) at /tmp/arduino-sketch-<some-numer>/*.map.
See below the map file, linker script and the output of print_memory_info of (wip) firmware application with 100_0 flash split.
Since my last print_memory_info I’ve done some memory optimizations. You can
see now tthat heap is 0x3c8f0 (248048; ~242 KB). In our case the heap is
smaller than in your case since we also have audio support which adds to the .pdm_section which takes from the RAM segment. We also allocate the out_buf on the heap which holds the out 92x92 image.
There’s also RAM_D2 and RAM_D3 sections which looks dedicated to lwip and openamp, respectively. RAM_D2 being 288 KB and RAM_D3 64 KB.
I’ll currently investigating whether these sections can be made free if not used by the application.
P.S.: At the bottom of your images in the Arduino IDE, after a build you see how much RAM is available to your application, in your case this was 355936 bytes. I didn’t know this either until I spotted it
> …the Portenta 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