STM32F446.Saving data in flash eeprom-like without using last big sector. Changing .ld file leads to malfunction.

[Diego Colombo]

Hi to all the community.

I have to save in non volatile memory some small amount of data,say 200 bytes.

STM32F446 has different sector sizes,

sectors 0,1,2,3 size= 16KB

sectors 4 size= 64KB

sectors 5,6,7 size=128KB

In other microcontrollers i was used to reserve last sector for saving my data.

In this case ,to me it looks a waste to reserve 128KB for such small amount of data.

Despite consecutive savings of data could be spreaded in emulated eeprom mode

and erase could be infrequent ,remains that this sector is no longer available for code.

For this reason i tried to use the first 16KB sector changing at linker level by the .ld file

(I'm using GNU with the good old AC& environment,because my PC is pretty old).

This method always worked using the last sector,but i have malfunction using first sector

MEMORY
{
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
 FLASH (rx)      : ORIGIN = 0x8004000, LENGTH = 496K
 MyFlashSector (rx)  : ORIGIN = 0x8000000, LENGTH = 16K
}
 
SECTIONS  /* Define output sections */
{
     .my_block1 0x8000000 :
  {
  KEEP(*(.MySector))
  } > 
.....

Then in C Code what i do is to declare my constant data

const uint16_t __attribute__((section (".MySector"))) CellsMem [100]={0xA200,0x8400,..

and trying to relocate the vector table in the first FLASH sector available

in system_stm32f4xx.c..If not ,not even the systick interrupt happens.

 SCB->VTOR = (FLASH_BASE | 0x4000);

In this case everything looks working,except that in debug it can't stop and restart from reset.

Is there anyway to correct this last point or everything needs to be changed?

If the topic has yet been posted and developed please,link it and i will delete this question,if it is repetitive.

Thanks

Diego ,

Milan,Italy

[Tesla DeLorean]

You can't use the first sector as that's where execution is expected to start. You need to split the flash into sections, carving a hole to free a couple of the smaller sectors.

Either use the first sector for a boot loader, or direct the linker script to divide, allocate and fill the two discontinuous flash sections, with the vectors in the front of the first.​

[Diego Colombo]

Thanks ,TeslaDeLorean,

Do you mean that i can use,for example, Sector 3 and the code can be splitted in sectors 1,2,4,5,6,7?

Please,can you post how the linker file should be?

I had successfull compilation in this way,but I'm not sure it is actually ok.

Thanks

MEMORY
{
RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 128K
 FLASH (rx)      	: ORIGIN = 0x8000000, LENGTH =  32K
 MyFlashSector (rx) : ORIGIN = 0x800C000, LENGTH =  16K
 FLASH2 (rx)      	: ORIGIN = 0x8010000, LENGTH = 464K
}
...
 
  /* Constant data goes into FLASH */
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH2

[Tesla DeLorean]

I don't have the available resources to post complete worked examples.

Yes, the form you show is the right approach. You might have to get more involved in the direction of code/data into the FLASH / FLASH2 sections, especially as things get larger, Probably easier to direct specific objects/libraries into the front FLASH sections, and then everything else into FLASH2. The GNU/GCC linker is not adept at balancing or spanning thing.

From a where did things get placed perspective you can review that in the .MAP file.

You could potentially skip the MyFlashSector section, the goal primarily is to keep certain areas out-of-play for the linker, and then you could directly refer to them in you own code, or via pointers, etc. This might be particularly helpful if you want to journal settings structures across the sector.