Filesystem size with custom STM32F7 build

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
User avatar
TravisT
Posts: 72
Joined: Sun Feb 23, 2014 2:31 pm
Location: Portland, OR
Contact:

Re: Filesystem size with custom STM32F7 build

Post by TravisT » Mon Aug 31, 2020 3:48 pm

Being busy often gets the best of me, but I would agree that the F767 should have an optimized 2MB version especially since it is on a mainstream dev board.

Since I have not pursued this router because I ended up choosing an external flash, I think once the dev board is working as hoped and after some other tweaks one of use can help make a pull request that manages at least a version of this with mile filesystem.
_______________
Travis Travelstead

User avatar
untitled
Posts: 24
Joined: Sat Nov 02, 2019 1:44 pm

Re: Filesystem size with custom STM32F7 build

Post by untitled » Sun Sep 13, 2020 10:25 pm

Sorry for no response. The baby has happened to our family so totaly not into micropython right now :D

The last sugested values didn't work for me. It shows increased storage space but crashes on data write. Will try more some day later.

User avatar
TravisT
Posts: 72
Joined: Sun Feb 23, 2014 2:31 pm
Location: Portland, OR
Contact:

Re: Filesystem size with custom STM32F7 build

Post by TravisT » Sun Sep 13, 2020 10:27 pm

Understand,
I have been too busy to play with it on my own hardware to confirm my suggestions. I know it can work but not sure what I am missing. The crash is usually due to a continuity issue and writing where it should not.
_______________
Travis Travelstead

Tom [AEMICS]
Posts: 1
Joined: Mon Oct 05, 2020 1:10 pm

Re: Filesystem size with custom STM32F7 build

Post by Tom [AEMICS] » Mon Oct 05, 2020 1:39 pm

Thanks to your discussion it seems I got things to work! Have a HTTP web server running now from internal flash memory.

I updated stm32f767.ld to represent the memory areas I wanted to use:

Code: Select all

MEMORY
{
    FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 2048K
    FLASH_ISR (rx)  : ORIGIN = 0x08000000, LENGTH = 32K     /* sector 0, 32K */
    FLASH_APP (rx)  : ORIGIN = 0x08008000, LENGTH = 2016K   /* sectors 1-11 3x32K 1*128K 7*256K */
    FLASH_FS (r)    : ORIGIN = 0x08008000, LENGTH = 1248K     /* sectors 1-8 (3*32K + 1*128K + 4*256K) */
    FLASH_TEXT (rx) : ORIGIN = 0x08140000, LENGTH = 768K    /* sectors 9-11 (3*256K)
    DTCM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K    /* Used for storage cache */
    RAM (xrw)       : ORIGIN = 0x20020000, LENGTH = 384K    /* SRAM1 = 368K, SRAM2 = 16K */
}
In mpconfigboard.mk the TEXT1_ADDR needed needs to be updated as well to match this:

Code: Select all

TEXT1_ADDR = 0x08140000
Changing the flashbdev.c file was a bit more difficult to get a grasp on. Apperently the FLASH_MEM_SEGx_START_ADDR and FLASH_MEM_SEGx_NUM_BLOCKS parameter sets are used to calculate the start addresses of a memory block. We are not able to use the full block size for blocks 5 t/m 8 (in my use case) since the DTCM data RAM can only store 128K. This means the memory range we use is not continuous and it needs to be specified in separate segments. Therefore I made a separate section for the STM32F767xx with multiple segements.

Code: Select all

#elif defined(STM32F767xx)

#define CACHE_MEM_START_ADDR (0x20000000) // DTCM data RAM, 128K
#define FLASH_SECTOR_SIZE_MAX (0x20000) // 128K max
#define FLASH_MEM_SEG1_START_ADDR (0x08008000) // sector 1
#define FLASH_MEM_SEG1_NUM_BLOCKS (704) // sectors 1,2,3,4,5: 32k+32k+32k=96k + 2*128k = 224k
#define FLASH_MEM_SEG2_START_ADDR (0x08080000) // sector 6
#define FLASH_MEM_SEG2_NUM_BLOCKS (256) // 1* 128k (of 256k)
#define FLASH_MEM_SEG3_START_ADDR (0x080C0000) // sector 7
#define FLASH_MEM_SEG3_NUM_BLOCKS (256) // 1*128k (of 256k)
#define FLASH_MEM_SEG4_START_ADDR (0x08100000) // sector 8
#define FLASH_MEM_SEG4_NUM_BLOCKS (256) // 1*128k (of 256k)
The flash address conversion needs to be updated as well to make use of the additional segments:

Code: Select all

static uint32_t convert_block_to_flash_addr(uint32_t block) {
    if (block < FLASH_MEM_SEG1_NUM_BLOCKS) {
        return FLASH_MEM_SEG1_START_ADDR + block * FLASH_BLOCK_SIZE;
    }
    if (block < FLASH_MEM_SEG1_NUM_BLOCKS + FLASH_MEM_SEG2_NUM_BLOCKS) {
        return FLASH_MEM_SEG2_START_ADDR + (block - FLASH_MEM_SEG1_NUM_BLOCKS) * FLASH_BLOCK_SIZE;
    }
    
    if (block < FLASH_MEM_SEG1_NUM_BLOCKS + FLASH_MEM_SEG2_NUM_BLOCKS + FLASH_MEM_SEG3_NUM_BLOCKS) {
        return FLASH_MEM_SEG3_START_ADDR + (block - FLASH_MEM_SEG1_NUM_BLOCKS - FLASH_MEM_SEG2_NUM_BLOCKS) * FLASH_BLOCK_SIZE;
    }
    
    if (block < FLASH_MEM_SEG1_NUM_BLOCKS + FLASH_MEM_SEG2_NUM_BLOCKS + FLASH_MEM_SEG3_NUM_BLOCKS + FLASH_MEM_SEG4_NUM_BLOCKS) {
        return FLASH_MEM_SEG4_START_ADDR + (block - FLASH_MEM_SEG1_NUM_BLOCKS - FLASH_MEM_SEG2_NUM_BLOCKS - FLASH_MEM_SEG3_NUM_BLOCKS) * FLASH_BLOCK_SIZE;
    }
    
    // can add more flash segments here if needed, following above pattern

    // bad block
    return -1;
}
It is a bit of a hack method, but it seems to work! Think it would be nicer to use the FLASH_SECTOR_SIZE_MAX in the address calculation, but it is not specified how many sectors are used in a segment. Another method would be to specify it as a struct, but then much more code would need to be rewritten. Ideas how to change this nicely are welkom!

User avatar
TravisT
Posts: 72
Joined: Sun Feb 23, 2014 2:31 pm
Location: Portland, OR
Contact:

Re: Filesystem size with custom STM32F7 build

Post by TravisT » Mon Oct 05, 2020 3:41 pm

Glad it worked!

Sorry I have been swamped and forgot about this thread. That last part is the part that has either changed, I forgot, or do not remember so I am glad it is noted here.
_______________
Travis Travelstead

User avatar
untitled
Posts: 24
Joined: Sat Nov 02, 2019 1:44 pm

Re: Filesystem size with custom STM32F7 build

Post by untitled » Mon Oct 05, 2020 9:26 pm

Awesome news! Gonna try it tomorrow

Post Reply