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? 

[Tesla DeLorean]

Posted on September 26, 2015 at 00:31

You create a scatter file or linker script which defines the location and areas of flash you can use for the program code, and then it won't touch the memory used for the EEPROM emulation, or whatever. You have to make sure when creating them you know the placement and sizes of the flash sectors.

In Keil you can create two distinct LOAD REGIONS, via IROM1, IROM2, etc that don't overlap each other, or the area you have set aside. The linker isn't smart enough to fill one then the other, you'd have to manage that manually. On an F4 the smarter move is just to have a boot loader in the first 16KB, then you have 3 16KB flash sectors for configuration, etc. and you place your Application code at the 64KB or 128KB mark.

[angeliran]

Posted on September 26, 2015 at 03:03

I'm reading what you say here clive, then I can set up in Keil v4, in IRAM 0x20000000 ???? I remove 1 kb, and it´s all?

[Tesla DeLorean]

Posted on September 26, 2015 at 03:36

I'm reading what you say here clive, then I can set up in Keil v4, in IRAM 0x20000000 ???? I remove 1 kb, and it´s all?

I'm not sure exactly what the question is. The linker will put things where you tell it too.

[estersci2]

Posted on September 26, 2015 at 09:24

Clive, 

Thanks, even when it comes to following Keils online instructions to find a standard linker file, they are out of  date for uV5 - so I'm completly lost. Is there any chance you could provide a sample that shows us on a practical level how to code a linker or scatter file to achieve this separation please? It's a pity one is not included with the flash firmware example since the example isn't worthwhile without it. Would it be possible to do it by tacking some code onto the end of the opt bytes .s file?Also, if we stuck with the standard linker file but stored our eeprom variables in the highest sector at end/top of memory, is it the case the keil will always lay the firmware image from the start/bottom of memory, and that a collision would only occur if the fw image got big enough?Thanks  

[Tesla DeLorean]

Posted on September 26, 2015 at 16:59

The linker puts things where you tell it too. If you shrink the size of the IROM region by 128KB, the linker will have 128KB LESS to use, and will complain that your image is too large if it doesn't fit in the space available to it.

Scatter file for F411E, 512KB of flash split so region from 0x08004000..0x0800FFFF is unused.

LR_IROM1 0x08000000 0x00004000 { ; load region size_region
ER_IROM1 0x08000000 0x00004000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
}
}
LR_IROM2 0x08010000 0x00070000 { ; load region size_region
ER_IROM2 0x08010000 0x00070000 { ; load address = execution address
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x00020000 { ; RW data
.ANY (+RW +ZI)
}
}

[angeliran]

Posted on September 26, 2015 at 18:39

Oh, i want to save, for example, 20 halfword variables, in non volatile memory (how i have in my discusion), like eeprom in pics (inside of my stm32f051r8, with 64 kb in flash), but i use hal libraries, I tried using EEPROM file, but I get different errors, so my last desicion, was to use directly flash (less complex), but I have tried in different ways, and I failed ...

[estersci2]

Posted on September 26, 2015 at 18:47

Clive - thanks, I can accross an interesting post involving you on this topic in 2012

Dear Clive1

Thank you so much. I understand what you mean already, i don't use page 0 for eeprom. I explain again if you see ok, please say YES

Configuration for KEIL

1) Set IROM1: Choose default  - Start: 0x8000000 Size: 0x400 Choose startup

2) Set IROM2: Choose default  - Start: 0x8003000 Size: 0xCC00:

Keil compiler will 

automatically 

separate 3 flash area for STM32F. Startup code and intiatially will start from address 

0x8000000 

and then avoid memory area from 

0x8000400 to 0x8002FF

 and then continue application code from address 

0x8003000

. As this result, we can use address from 

0x8000400 to 0x8002FF for eeprom emulation, that don't interfere with any memory area.

Thanks and Best regards,

Toan Thieu

0x08000400 to 0x08002FFF, but yes

If can squeeze data into this space, we should be ok with default file...

[angeliran]

Posted on September 26, 2015 at 20:47

Hi new guy, if i don´t understand bad, ROM, it is read only memory (and there is stored the alias code, i think, somebody correct me if i´m wrong), so i have thinking, the mod must be in RAM, but it have less space... For eeprom emu, i remember it need 2 or 3 pages, so you need 2 or 3 kb... we need to wait Clive... And it´s recommended, to use the last memory space available...

UPDATE: Ok, I tried it for both cases, I took them 1 kb (0x400) to either of the 2 (IRAM and IROM) With IROM, no changes. With iRAM yes, but I see more information, so I guess Iam touching important information. that frustrating ... = (

[Tesla DeLorean]

Posted on September 26, 2015 at 23:32

Ok, from Keil's perspective IROM is INTERNAL READ ONLY MEMORY, it's whatever the primary Non-Volatile Memory is in your part, ROM, EPROM, FLASH, etc., the compiler/linker doesn't care if it's a Mask ROM image you send to the factory, or one you JTAG onto the part.

Different STM32 Families have different FLASH memory configurations, and this will drive the particular sectors you use, the F0/F1 family have SMALL UNIFORM sectors (1K), and here it's easier to pick the ones at the end, because a) you can have a long single run of sectors, and b) the ones at the beginning are needed for booting. With the F2/F4 family the sectors are NON-UNIFORM, they are of different sizes, the small ones at the front (16/16/16/16/64K), the large ones (128K) throughout the bulk of the part. The large sectors are very slow to erase, think seconds, the small ones erase faster, and are less wasteful if you're writing small amounts of data. You can't use the first one easily, because it needs to contain the initial SP/PC for booting, and thus you have to make a hole in the FLASH to accommodate the use of the small sectors for the EEPROM Emulation, or other more effective configuration writing schemes. I'm not sure why RAM keeps coming up, it's not relevant to the EEPROM emulation, or how the linker partitions the memory. Where it does play a part in Cortex-M0 parts is where you want to relocate the Vector Table, as only the base of FLASH or RAM can be used to map this data in the Zero Address Space. May be a good time to read a few good books on Micro Processors and chip/board level implementations.