GIGA:/Portenta H7 can not malloc(51200) current ArduinoCore-zephyr

[KurtE]

Describe the bug
Can not 51k of memory, currently my test programs for GIGA display are all bus faulting

Target board + cli verbose compilation output
Arduino GIGA with a GIGA display

Full verbose compilation output, ideally with arduino-cli invocation or from IDE 2.3.3+

Output of Serial Monitor

*** Booting Zephyr OS build v4.2.0-27-g09722075b043 ***
[00:00:04.497,000] <inf> usb_cdc_acm: Device suspended
[00:00:04.759,000] <inf> usb_cdc_acm: Device configured
Buffer: 0

Optional: attach the sketch

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  while (!Serial && millis() < 5000) {}
  pinMode(LED_BUILTIN, OUTPUT);

  void *buffer = malloc(51200);
  Serial.println((uint32_t )buffer, HEX);
  printk("Buffer: %p\n", buffer);
}

void loop() {
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  delay(500);
}

Additional context
In real sketch I was trying the malloc was part of:

  //Allocate memory to the framebuffer
  uint32_t sizeof_framebuffer = 2 * 160 * 160;
  void* ptrFB = malloc(sizeof_framebuffer);
  printk("\tptrFB: %p %u\n", ptrFB, sizeof_framebuffer);
  // Cast the void pointer to an int pointer to use it
  uint8_t* frameBuffer = static_cast<uint8_t*>(ptrFB);

  printk("Before setFrameDesc\n");
  display.setFrameDesc(160, 160, 160, sizeof_framebuffer);
  printk("After setFrameDesc\n");
  display.startFrameBuffering();
  printk("After startFrameBuffering\n");
  fillScreen(RGB565_DARKGREY);

Debug output from that sketch:

*** Booting Zephyr OS build v4.2.0-27-g09722075b043 ***
height: 480, width: 800, rotated: 1
setup called
[00:00:04.503,000] <inf> usb_cdc_acm: Device suspended
[00:00:04.766,000] <inf> usb_cdc_acm: Device configured
Display::begin(0) called
        1
        2
        3 1 0
        4
        5
- Capabilities:
  x_resolution = 480, y_resolution = 800
, supported_pixel_formats = 105
  current_pixel_format = 32, current_orientation = 0
After display.begin() 1
Before getrameBuffer
        FB: 0xc0000080
        ptrFB: 0 51200
Before setFrameDesc
After setFrameDesc
After startFrameBuffering
[00:00:04.879,000] <err> os: ***** BUS FAULT *****
[00:00:04.886,000] <err> os:   Precise data bus error
[00:00:04.894,000] <err> os:   BFAR Address: 0x10000
[00:00:04.902,000] <err> os: r0/a1:  0xc0000440  r1/a2:  0x00010000  r2/a3:  0x0001efbc
[00:00:04.905,000] <err> os: r3/a4:  0xc0000c61 r12/ip:  0x00000000 r14/lr:  0x0809c937
[00:00:04.916,000] <err> os:  xpsr:  0x81000000
[00:00:04.923,000] <err> os: s[ 0]:  0x00001000  s[ 1]:  0x2405bc90  s[ 2]:  0x00000000  s[ 3]:  0x2405bca8
[00:00:04.928,000] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x0804715f  s[ 6]:  0x2405bd04  s[ 7]:  0x00000000
[00:00:04.941,000] <err> os: s[ 8]:  0x2405bd04  s[ 9]:  0x2403058b  s[10]:  0x00001000  s[11]:  0x00000000
[00:00:04.946,000] <err> os: s[12]:  0x0000000c  s[13]:  0x0809219d  s[14]:  0x0000c800  s[15]:  0x00000004
[00:00:04.951,000] <err> os: fpscr:  0x24073348
[00:00:04.959,000] <err> os: Faulting instruction address (r15/pc): 0x080a7ae6
[00:00:04.969,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:04.971,000] <err> os: Current thread: 0x240060c8 (main)
[00:00:04.980,000] <err> os: Halting system
uart:~$ Timeout while waiting for high throughput clock

[KurtE]

Checked the simple sketch on Portenta H7 as well and it fails to malloc as well

[mjs513]

This was also noticed while trying to use our graphics library to display video.

As a test ran the graphics display test sketch and saw the problem again. When initializing display buffer with SDRAM or shared multiheap would fail the same way, with the exception being "Imprecise data bus error"

Using shared multiheap:

Zephyr
height: 480, width: 800, rotated: 1
RGB565 set
Shared multiheap
sizeof: 768000
w: 480, h:800, buf: 768000
[00:00:05.023,000] <err> os: ***** BUS FAULT *****
[00:00:05.030,000] <err> os:   Imprecise data bus error
[00:00:05.038,000] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x00000000
[00:00:05.049,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x08092751
[00:00:05.060,000] <err> os:  xpsr:  0x41000000
[00:00:05.068,000] <err> os: s[ 0]:  0x00001397  s[ 1]:  0x24073d18  s[ 2]:  0x000001e0  s[ 3]:  0x00000320
[00:00:05.080,000] <err> os: s[ 4]:  0x000001e0  s[ 5]:  0x08092163  s[ 6]:  0x000bb800  s[ 7]:  0x00000000
[00:00:05.093,000] <err> os: s[ 8]:  0x24020ae4  s[ 9]:  0x08092751  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:05.105,000] <err> os: s[12]:  0x24032f9a  s[13]:  0x2405bc7c  s[14]:  0x24073d18  s[15]:  0x08092173
[00:00:05.118,000] <err> os: fpscr:  0x24032f9a
[00:00:05.125,000] <err> os: Faulting instruction address (r15/pc): 0x08047164
[00:00:05.135,000] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
[00:00:05.145,000] <err> os: Current thread: 0x24006060 (main)
[00:00:05.154,000] <err> os: Halting system

This occurs when calling set frame description.

Please note: When using 0.51.0 there were no issues and video displayed on the giga display no problem

[mjs513]

Just reran @KurtE's sketch

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  while (!Serial && millis() < 5000) {}
  pinMode(LED_BUILTIN, OUTPUT);

  void *buffer = malloc(51200);
  Serial.println((uint32_t )buffer, HEX);
  printk("Buffer: %p\n", buffer);
}

void loop() {
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  delay(500);
}

with the 0.51.0 configure file and malloc seems to working now. Sketch returns
2403BD10

So again with all the new stuff added there is no room to do much of anything else. See: #274 for further info.

[KurtE]

Note: I created a thread on the forum with additional information:
https://forum.arduino.cc/t/giga-portenta-h7-difficulties-with-malloc-on-zephyr-0-52/1415377

Looks like the maximum malloc went from: 272kb in build 0.51 to 48 in build 0.52!

[pennam]

@KurtE we have enabled some new features in 0.52.0 release and obviously RAM consumption is increased 😢 . Looking at the memory region summary after building the loader you should see something like this:

Memory region         Used Size  Region Size  %age Used
           FLASH:      592088 B       640 KB     90.35%
             RAM:      471856 B       512 KB     90.00%
          EXTMEM:          0 GB        16 MB      0.00%
           SRAM1:          0 GB       128 KB      0.00%
           SRAM2:          0 GB       128 KB      0.00%
           SRAM3:          0 GB        32 KB      0.00%
           SRAM4:          0 GB        64 KB      0.00%
          SDRAM1:          4 MB         8 MB     50.00%
        IDT_LIST:          0 GB        32 KB      0.00%

doing some math ((512 * 1024) - 471856)/1024 = you will get your 51K you are able to use with malloc().

SRAM1-2-3-4 seems to be unused, I'm doublechecking it because i'm not 100% sure they are not used is some non conventional way. In any case as of now they are not usable with malloc()

SDRAM1 is used at 50% and added to the shared_multi_heap. DISPLAY and VIDEO peripherals are using this memory reagion to allocate buffer, you can check in the config file searching for _USE_SHARED_MULTI_HEAP.

I will check if all 4MB are used, but I'm pretty sure they are not so you should be able to use also this memory region to allocate your buffers using shared_multi_heap API.

[KurtE]

Thanks @pennam - Your numbers make sense, by the time the sketch gets to it, the max I could allocate was 48K.

And in some cases we have used the shared_multi_heap. But I personally believe that there are a ton of libraries and
sketches that call malloc and I assume new() use to allocate buffers, and many of them assume they have enough memory
available... Not sure one should expect that all the libraries should need to change to some other memory allocator...

@KurtE we have enabled some new features in 0.52.0 release and obviously RAM consumption is increased 😢 . Looking at the memory region summary after building the loader you should see something like this:

Yes something like an additional 240+K used up between the last two releases.

Which is one of the reasons I have experimented with for example cameras to not have them initialize their objects
unless someone actually uses one. I personally think it is a good idea to not start up the timer and initialize all of the pins, etc
unless the sketch is actually going to use the camera.
#195

Which in 2+ months since I submitted it, not sure if anyone has looked at it. I think a lot of the other features could hopefully
all only be initialized and use up buffer space, if the sketches actually use it?

Like on the current release, when the sketch starts up, I see a lot more stuff on the debug window, that was not there before:

Timeout while waiting for high throughput clock
SDIO firmware download error, whd_bus_sdio_init failed at 559
Interface is not up/NULL and failed in function whd_deinit at line 203
Interface is not up/NULL and failed in function whd_wifi_get_mac_address at line              3184

[00:00:04.899,000] <inf> flashdisk: Initialize device wlan
[00:00:04.907,000] <inf> flashdisk: offset 1000, sector size 4096, page size 409             6, volume size 1044480
[00:00:04.920,000] <inf> flashdisk: Initialize device ota
[00:00:04.927,000] <inf> flashdisk: offset 100000, sector size 4096, page size 4             096, volume size 5242880
[00:00:04.940,000] <inf> littlefs: littlefs partition at /storage
[00:00:04.949,000] <inf> littlefs: LittleFS version 2.11, disk version 2.1
[00:00:04.958,000] <inf> littlefs: FS at qspi-nor-flash@0:0x700000 is 1792 0x100             0-byte blocks with 512 cycle
[00:00:04.971,000] <inf> littlefs: partition sizes: rd 16 ; pr 4096 ; ca 4096 ;              la 32
[00:00:04.982,000] <inf> littlefs: Automount /storage succeeded
*** Booting Zephyr OS build v4.2.0-31-g8e71141c1b0a ***
[00:00:05.015,000] <inf> usb_cdc_acm: Device suspended
[00:00:05.264,000] <inf> usb_cdc_acm: Device configured
uart:~$

Before all I saw was the stuff starting at *** Booting...