MicroPython Forum (Archive)

Hi,
STM32F405 have 64 kbyte of CCM data RAM. As I understand, this is special RAM, and only CPU accessing to it. How micropython uses this memory? Why is it so big (1/3 of RAM)? Is it possible to relocate, for example, UART cache here? May I use it in someway?
Thanks.

Currently, I believe that its being used by the flash driver.

The internal flash file system has a 64K block in it. In order to rewrite that block, you need to read the 64K block into memory, make your modifications, erase the block in flash, and then write flash block back out.

https://github.com/micropython/micropyt ... rage.c#L40

Thank you.
But what about writing on sd card? I found that some flashes have 128 kbyte blocks.

Writing to the sdcard just requires enough for a single block (or maybe a cluster). It should be less than 64K. The flash blocks

The pyboard flash has 4 x 16K, 1 x 64K, and the remainder are 128K.

The internal flash storage is stored on 3 of the 16K + the 64K which is where the 112K comes from, and we don't have enough RAM to support putting any of the 128K blocks into the storage area.

If you were to disable the internal storage area, then I think that the 64K could be used for other purposes (as long as it isn't being used as cache for the sdcard).

Is it possible to add option in boot.py, so that micropython may use CCM as part of RAM (with read-only mode for internal flash), when I use only external Micro SD? I think it could be efficient for some scripts.

There currently isn't any such option.

Ok. I hope it will be implemented in the future.
Thank you.

The issue is that current garbage collection implementation in uPy requires continuous heap. So, there're 2 steps to make use of CCM:

1. Refactor current GC implementation so it was more pluggable, and can be replaced with another implementation(s).
2. Write GC implementation supporting CCM.

Interested users are welcome to contribute to both areas. Otherwise, you can just treat CCM as reserved memory available only to drivers (you can also write your own driver using it for its needs, after making sure that usage doesn't conflict with other drivers).

One issue is that machine code cannot be executed from CCM, so it can only hold bytecode functions.

CCM could hold the stack, freeing up some of the main RAM.

On the user side of things, could add an option to pyb.mount to remount the flash readonly. Doing this would then repurpose the CCM for heap or stack.