cancel
Showing results for 
Search instead for 
Did you mean: 

Flash as EEPROM / FW Code Image Collision (avoiding)

estersci2
Associate III
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? 
13 REPLIES 13
angeliran
Senior
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) iROM1

start: 0x8000000

size: 0x10000

I want to leave free for EEPROM emulation, or flash to be writing, sector 14, which begins on page 56, dir. 0x0800e000 to 0x0800e3ff

I have to change to:

(selected) iROM1

start: 0x8000000

size: 0xe400

add:

(selected) iROM2

start: 0x800F000

size: 0x1000

With 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...

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
angeliran
Senior
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    iROM1

0x0C00 ---> 3,072 kb <----- here, not stated in keil, I can use?

0x1000 ---> 4,096 kb   iROM2

Posted on September 28, 2015 at 02:40

Yes

0x08000000..0x0800E3FF (0xE400) IROM1

0x0800E400..0x0800EFFF (0x0C00) EEPROM - OUT OF LINKER's VIEW

0x0800F000..0x0800FFFF (0x1000) IROM2

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..