Flash EEPROM Simulation Question

Posted on June 27, 2013 at 20:58

You're not going to be able to use the first sector for random crap, it needs to be a bootloader or something with a vector table. After the processor starts you can relocate it someplace else, for say application code residing at 0x08010000

All the die have 1 MB, the 256 KB parts just have a bunch of 128 KB sectors untested/unused.

Posted on June 28, 2013 at 08:41

Thanks, does that mean that the rest of the 1MB  after the program code is available for user data?

 

From: clive1

Posted: Thursday, June 27, 2013 8:58 PM

Subject: Flash EEPROM Simulation Question

You're not going to be able to use the first sector for random crap, it needs to be a bootloader or something with a vector table. After the processor starts you can relocate it someplace else, for say application code residing at 0x08010000

All the die have 1 MB, the 256 KB parts just have a bunch of 128 KB sectors untested/unused.

Posted on June 28, 2013 at 13:11

Thanks, does that mean that the rest of the 1MB  after the program code is available for user data?

It means it's there and untested, might disappear if they create an ''optimized die'', and might contain multiple bit failures. Generally one should consider it untrusted, and ponder liability issues should it fail.

The 128K sectors erase very slowly, thus have less utility than the 16K ones.

All the die have a full complement of RAM, and given the poorly documented/executed demarcation of 112K + 16K, changing that will likely result a large amount of latent failure, as the inferred behavior is that all parts have 16K at 0x2001C000, but all the tool chains assume the memory is linear. ie does a 96K part really have 80K + 16K with a 32K hole at 0x20014000?

You can plan the use of the memory in many way, if you don't want a boot loader the application could have a 32 or 16K hole to accommodate the EEPROM emulation, and user data (file system, graphics) could be placed after the executable code.

Posted on June 28, 2013 at 13:48

Thanks a lot Clive.

Good point regarding the 32K ''Hole''!

Will do some more reading...I am still new at STM32 and still need to figure out a lot of stuff. 

Posted on June 28, 2013 at 15:58

''Holes'' in the flash space are not a big problem if you use the linker script. I map out sectors 2-3 from code space through the linker, and then manually assign certain code sections to the first 32K, mostly large ''const'' tables plus the vector table. There is some hand optimization to make use of that first flash sectionbut it's not a difficult procedure. Use the attribute section modifier to put const tables or code sections in a named region assigned to the first 32K.

GCC example: 
DctOBJECT __attribute__ ((section(''.dict''))) Dictionary[] = 
Fragment from GCC Linger script: 
.progid : 
{ 
. = ALIGN(4); /* word align */ 
_sflash0 = .; /* start of flash sector 0 */ 
KEEP (*(.isr_vector)) /* place Cortex M3 vectors first */ 
*(.progid .progid.*) /* followed by firmware ID */ 
*(.dict*) /* followed by object dictionary */ 
*(.ARM.exidx* .gnu.linkonce.armexidx.*) 
. = ALIGN(4); /* word align */ 
_eflash0 = .; /* end of flash sector 1 */ 
} > FLASH0 

This GCC example assigns a constant table to the ''.dict'' memory region. The linker script loads it into the ''FLASH0'' region, defined as the first 32K of flash. Jack Peacock