[TM4C123] storage and flash

[ExXec]

Hi,
I'm currently working on the integrated flashfs and I wanted to know, if the code of the storage module is controller specific or if I just need to tweak some defines to make it work?

And what modules are responsible for the flashfs? I assume its more than the storage module

thanks
-ExXec

[ExXec]

Another queston:

I have a library for flash access, should I use that (and where would I put it?) or keep he uPy implementation?

[dhylands]

Hi,
I'm currently working on the integrated flashfs and I wanted to know, if the code of the storage module is controller specific or if I just need to tweak some defines to make it work?

And what modules are responsible for the flashfs? I assume its more than the storage module

thanks
-ExXec

The code for FatFS can be found here: https://github.com/micropython/micropyt ... ib/oofatfs It's processor independent. It doesn't include the code which actually reads/writes the flash blocks. That code will be processor specific.

For the stm32, the flashbdev.h/.h file contain the block device code which is used for the filesystem. It knows the layout of the flash, and knows where the filesystem lives. It will translate block addresses used by the filesystem into flash addresses. Then there is flash.c which knows how to write flash but knows nothing about filesystems.

[dhylands]

Another queston:

I have a library for flash access, should I use that (and where would I put it?) or keep he uPy implementation?

You'll want to use it in place of flash.c (from the stm32 implementation). You'll also need to come up with a replacement for flashbdev.c since your MCUs flash layout will be totally different than the stm32 one.

[ExXec]

Ok, so I just need to do the flash.c and flashbev and then init the filesystem in the main or something, if I understand you correctly.

This means, that I don't need the storage module for this? What does that one do?

Anyway, thanks for your answers, I really appreciate your help.

- ExXec

[dhylands]

In stm32 the storage.c file is used to support the USB Mass Storage, so there is some overlap with the filesystem code, but I don't think you need storage.c if you're not using something like USB Mass Storage.

[ExXec]

ah I see.

More questions arise:
I tried to redo the flash.c file and had some problems:
the flash_erase() function has two arguments, one is the address an one is num_word32
> is the address sector-aligned or do I have to find the start address of the corresponding sector myself?
> what does num_word32 contain? Number of words to erase would be the obvious guess, but flash can only erase whole sectors. How does this work here? Do I need to check if the number of words is bigger than one sector?

And how are those functions called from the fs, in the oofatfs, there is no indication of those functions only disk_read etc.
Is there another layer to rewrite for my MCU, or will it just work when flash.c is done?

Thanks again

-ExXec

[dhylands]

Looking through the code, the only place that flash_erase is called is from here:
https://github.com/micropython/micropyt ... dev.c#L233
so it looks like num_word32 is the number of 32-bit words being erased.

I would imagine that the address needs to point to the beginning of the flash sector being erased.That will most likely be processor specirfic.

[ExXec]

I see,

Another question (sorry ):
My linker script defines the regions as follows

Code: Select all

MEMORY
{
    FLASH (RX) : ORIGIN = 0x00000000, LENGTH = 0x00040000
    SRAM  (WX) : ORIGIN = 0x20000000, LENGTH = 0x00008000
}

Do I need to make FLASH (WX) for the fs to work?

[dhylands]

I don't think so. The main purpose for the sections in the .ld file is to reserve address ranges and make sure code doesn't collide with the fs.