Question about RAM

[rkompass]

Hello @nspsck,

because we were at it: I just wanted to ask you a question, we may close this issue immediately afterwards. But perhaps you decide this belongs to the MP discussons...

With the Blackpill I now have, due to your efforts, in comparison to Pyboard 1.1

MicroPython v1.21.0 on 2023-10-06;   MicroPython v1.22.0-prev on 2023-11-19;
PYBv1.1 with STM32F405RG             WeAct Studio Blackpill v3.1 8MB with STM32F411CE
>>> import pyb                       >>> import pyb
>>> pyb.info()                       >>> pyb.info()
ID=31004800:01504857:4b343720        ID=5b002e00:04513030:33343331
DEVID=0x0413                         DEVID=0x0431
REVID=0x1007                         REVID=0x1000
S=168000000                          S=96000000
H=168000000                          H=96000000
P1=42000000                          P1=24000000
P2=84000000                          P2=48000000
_etext=8075064                       _etext=80516ec
_sidata=807506c                      _sidata=80516f4
_sdata=20000000                      _sdata=20000000
_edata=20000034                      _edata=20000034
_sbss=20000034                       _sbss=20000034
_ebss=20002358                       _ebss=2000346c
_sstack=2001bff8                     _sstack=2001bff8
_estack=2001fff8                     _estack=2001fff8
_ram_start=20000000                  _ram_start=20000000
_heap_start=20002358                 _heap_start=2000346c
_heap_end=2001bff8                   _heap_end=2001bff8
_ram_end=20020000                    _ram_end=20020000
qstr:                                qstr:
  n_pool=2                             n_pool=2
  n_qstr=25                            n_qstr=25
  n_str_data_bytes=242                 n_str_data_bytes=244
  n_total_bytes=722                    n_total_bytes=724
GC:                                  GC:
  103168 total                         98880 total
  10544 : 92624                        10304 : 88576
  1=228 2=35 m=40                      1=210 2=35 m=40
LFS free: 90624 bytes                LFS free: 8302592 bytes
                                     THREAD: only main thread

>>> import gc                        >>> import gc
>>> gc.collect();gc.mem_free()       >>> gc.collect(); gc.mem_free()
98432                                95440

But the pyboard has a STM32F405RG with 192K RAM !!! I would expect at least +40-50K more RAM, but there is only +3K more available. Do you have an explanation for this? Is there something grossly misconfigured? Both show _ram_end=20020000, shouldn't it be another value for the Pyboard?

[rkompass]

O.k., I get it. It's the 64K cache for the flash. Somewhere defined, but not reported in the pyb.info().

And the additional 64K RAM is CCM RAM. One may use it though: https://forum.micropython.org/viewtopic.php?f=3&t=3702.

Jimmo stated in Feb 2021 there:

The heap is limited by the available RAM. The default configuration uses all available RAM (left over after .bss and .data).

The only exception is that the CCM is reserved for the block cache. Making that available to the heap would require supporting multiple non-contiguous regions, but isn't currently available.

That should have changed recently, iirc. So in principle there would be away now to have more Heap.

[nspsck]

Hi! You are right, that is used as flash cache.

This ugh.. is kinda awkward for the current state of the micropython.

The problem is that the F405's RAM is split into 2 sections. One SRAM (1 and 2, 112K+16K) and one CCM (64K), as you can check in the manual: But the gc in micropython requres the memory (RAM) to be continous. Which means, the 64K CCMRAM can not be utilized otherwise. (Maybe as a RAM-disk, but I haven't tried it out yet).

If you were looking for a device with more RAM, I suggest you to checkout the STM32F412RE also made by WeAct Studio. I have a definition for that board as well. It does not have a SPI-Flash but you can get yourself a SD-card, configure it to be mounted on boot and use that to store all your codes and data. It's basically a F411 with more RAM.

[rkompass]

I edited: Jimmo stated in Feb 2021 there:

The heap is limited by the available RAM. The default configuration uses all available RAM (left over after .bss and .data).

The only exception is that the CCM is reserved for the block cache. Making that available to the heap would require supporting multiple non-contiguous regions, but isn't currently available.

That should have changed recently, iirc. So in principle there would be away now to have more Heap.

After hearing your comment/opinion I should ask Jimmo in discussions??

[nspsck]

That should have changed recently, iirc. So in principle there would be away now to have more Heap.

Are they officially moving stack into the CMMRAM? That's some really exciting news! Thanks for the information!

[rkompass]

No. I just noted that there is now a way to have the heap using 2 different RAM regions.

But for the CMMRAM that would probably still be problematic, as there are operations like timed ADC or DAC, that use the DMA under the hood. I should ask Jimmo if it's possible now.

[nspsck]

Oh, ok.

But for the CMMRAM that would probably still be problematic, as there are operations like timed ADC or DAC, that use the DMA under the hood. I should ask Jimmo if it's possible now.

As Damien said in that thread, it's probably safe to do so.

So it should be OK to put the stack into CPU-only RAM, ie not accessible by DMA.

I guess you just have to modify these lines.

[rkompass]

Are they officially moving stack into the CMMRAM?

Not officially. But chrismas9 did it in the above linked MP forum post:

By reducing the cache size and moving the stack into the second RAM block I can increase the heap by 16k.

And there was no problem. However then that was only the 16K stack. Freeing 16K for the Heap

[rkompass]

Those are the lines !

I should search for the secondary heap: Found heap autosplit. What do you think: Could that be applied to CCM RAM?

[nspsck]

That is a great feature!

Tho, after a very brief look into it, I believe that is designed towards the esp32port and recently been replaced/reorganized into the new MICROPY_GC_SPLIT_HEAP. And this tag seems only to be relevant for the esp32 port.

[rkompass]

So the 16K stack relocation is realistic, the heap split not. Also not for this:

The DMA on the STM32 is currently used for the following: SD card, DAC, SPI, I2C. The DAC, SPI and I2C are pretty much exclusively called by Python code with buffers allocated on the heap. SD card read/write can be called from Python with a buffer on the heap, or the USB MSC driver which has a statically allocated buffer in the BSS segment.

So it should be OK to put the stack into CPU-only RAM, ie not accessible by DMA.

I will try to compile this in, once I do a compilation session :-)