[STM32F412RG] porting micropython flash memory problems

[AndreasB]

Hi,
I am currently porting micropython to a custom board using a STM32F412RG.
the reason of using this chip is the larger flash and ram capacity compared to the STM32F411RE.
I have gotten so far as succesfully flashing a build to the board but now i am running into problems with the storage.
the board keeps crashing every time i am writing data to the internal flash past the 46KB of used storage.
My suspicion is I somehow have the file system wrongly defined.
what i have in my stm32f412.ld file

Code: Select all

MEMORY
{
    FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K /* entire flash */
    FLASH_ISR (rx)  : ORIGIN = 0x08000000, LENGTH = 16K /* sector 0 */
    FLASH_FS (rx)   : ORIGIN = 0x08004000, LENGTH = 112K /* sectors 1,2,3 are 16K, 4 is 64K, 5 is 128K (64K used) for filesystem */
    FLASH_TEXT (rx) : ORIGIN = 0x08020000, LENGTH = 896K /* sectors 7,8,9,10,11 are 128K*/
    RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 256K
}

/* produce a link error if there is not this amount of RAM for these sections */
_minimum_stack_size = 2K;
_minimum_heap_size = 16K;

/* Define tho top end of the stack.  The stack is full descending so begins just
   above last byte of RAM.  Note that EABI requires the stack to be 8-byte
   aligned for a call. */
_estack = ORIGIN(RAM) + LENGTH(RAM);

/* RAM extents for the garbage collector */
_ram_start = ORIGIN(RAM);
_ram_end = ORIGIN(RAM) + LENGTH(RAM);
_heap_start = _ebss; /* heap starts just after statically allocated memory */
_heap_end = _ram_end - 16K; /* 240K, tunable */

and what i have edited into flashbdev.c

Code: Select all

#elif defined(STM32F412Rx)

STATIC byte flash_cache_mem[0x4000] __attribute__((aligned(4))); // 16k
#define CACHE_MEM_START_ADDR (&flash_cache_mem[0])
#define FLASH_SECTOR_SIZE_MAX (0x4000) // 16k max due to size of cache buffer
#define FLASH_MEM_SEG1_START_ADDR (0x08004000) // sector 1
#define FLASH_MEM_SEG1_NUM_BLOCKS (224)  // sectors 1,2,3,4,5: 16k+16k+16k+64k+64k(of 128k)=176k

and in mpconfigboard.mk

Code: Select all

MCU_SERIES = f4
CMSIS_MCU = STM32F412Rx
AF_FILE = boards/stm32f412_af.csv
LD_FILES = boards/stm32f412.ld boards/common_ifs.ld
TEXT0_ADDR = 0x08000000
TEXT1_ADDR = 0x08020000

Help with this would be very much appreciated.

[dhylands]

In order to use 64k of one of the 64k flash blocks, you'll need to increase the size of flash_cache_mem from 16k to 64k.

[AndreasB]

In order to use 64k of one of the 64k flash blocks, you'll need to increase the size of flash_cache_mem from 16k to 64k.

oke how should i go about doing that because that happens to be the part of the code i don't understand (i coppied it from the f411)

Code: Select all

STATIC byte flash_cache_mem[0x4000] __attribute__((aligned(4))); // 16k
#define CACHE_MEM_START_ADDR (&flash_cache_mem[0])
#define FLASH_SECTOR_SIZE_MAX (0x4000) // 16k max due to size of cache buffer

all the others use a CCM ram or DTCM ram for it which the F412 doesn't have that
or is it safe to just change FLASH_SECTOR_SIZE_MAX to 0x10000

[AndreasB]

oke i got it fixed

Code: Select all

STATIC byte flash_cache_mem[0x10000] __attribute__((aligned(4))); // 16k
#define CACHE_MEM_START_ADDR (&flash_cache_mem[0])
#define FLASH_SECTOR_SIZE_MAX (0x10000) // 16k max due to size of cache buffer

this works now

[chrismas9]

I recently did the F413 port. Unless you need Ethernet consider using it instead, or try using it as a starting point instead of F411. It needed a few changes to the port source files, not just a custom config. For example the generic F4 startup file does not support some interrupt vectors like SPI 4&5.

[AndreasB]

I recently did the F413 port. Unless you need Ethernet consider using it instead, or try using it as a starting point instead of F411. It needed a few changes to the port source files, not just a custom config. For example the generic F4 startup file does not support some interrupt vectors like SPI 4&5.

I actually saw that and compared my own source code adjustments on that.
the board has already been produced as a prototype at this moment so its a little bit inconvenience to change micro at this moment.
the spi 4 and 5 interrupt vectors are not needed for my implementation but I will see if other changes are needed.
It is something i might consider looking at if I have some free time to port it properly for general use.
but for now i will just work with my own quick and dirty solution.