Flash as EEPROM / FW Code Image Collision (avoiding)

[estersci2]

Posted on September 26, 2015 at 00:16

Hi,

I am working from the olfd Std FW peripheral libs - gave up on cube.There is an interesting ''flash'' example project for storing run-time configuration variables.It has sectors/addresses defined so you can decide what block of memory to use for your run-time storage operation. What I wanted to ask is this. Is there some way to be assured that the location I select for run-time flash write operations will not clash/overwrite that sector of memory used to store the firmware image itself?Is there something in the the ''flash'' example that gaurantees it - for example are the storage sectors defined somehow gauranteed not to be used for fw image storage, or is it all the same pool of flash?Is there a possibility of a sample scatter file somewhere that can be used to enforce separation (keil v5)?Or if there is some other established wisdom on how to handle this risk, please let me know. Also, I find the forum is serving up garbage data for all but the most recent posts - is this happening for others or is it just my ancient pc? 

[angeliran]

Posted on September 27, 2015 at 01:26

Thank you very much for answering Clive, then, based on your comment, in my case (for stm32f0), I have to cut in Keil, where it says:

(selected) iROM1start: 0x8000000size: 0x10000I want to leave free for EEPROM emulation, or flash to be writing, sector 14, which begins on page 56, dir. 0x0800e000 to 0x0800e3ffI have to change to:(selected) iROM1start: 0x8000000size: 0xe400add:(selected) iROM2start: 0x800F000size: 0x1000With this, I'll have a hole of 4 KB for the job?UPDATE:I have wrote this:int xx;int mm=1000;HAL_FLASH_Unlock();for(xx=0;xx<mm;xx++){}  SET_BIT(FLASH->CR, FLASH_CR_PER);  WRITE_REG(FLASH->AR, 0x0800e000);  SET_BIT(FLASH->CR, FLASH_CR_STRT); for (xx=0;xx<mm;xx++){}  HAL_FLASH_Program(TYPEPROGRAM_HALFWORD, 0x0800e000, 0x5678);for (xx=0;xx<mm;xx++){}HAL_FLASH_Lock();uint16_t dato;  /* Infinite loop */  /* USER CODE BEGIN WHILE */  while (1){   dato=*((uint16_t *) 0x0800e000); if (dato==0x5678){ HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_9);} HAL_Delay(500); }And i do debug in keil, see memory address: 0x0800e000, and no change...Physically i can´t see the led toggling, so, no memory writing...Tomorrow continue...

[Tesla DeLorean]

Posted on September 27, 2015 at 03:13

Look, if you're writing data at 0xE000, you want to tell the linker the length of IT'S area is 0xE000 and not 0xE400, you're trying to stop the linker putting data in the area you want to use.

[angeliran]

Posted on September 28, 2015 at 01:54

Ok Clive, it based on the idea that I could understand:

Keil flash will divide into 3 parts:Flash memory partitions:0xE400 ---> 58.368 kb    iROM10x0C00 ---> 3,072 kb <----- here, not stated in keil, I can use?0x1000 ---> 4,096 kb   iROM2

[Tesla DeLorean]

Posted on September 28, 2015 at 02:40

Yes

0x08000000..0x0800E3FF (0xE400) IROM10x0800E400..0x0800EFFF (0x0C00) EEPROM - OUT OF LINKER's VIEW0x0800F000..0x0800FFFF (0x1000) IROM2