I was reading up on the flash eeprom and best I can tell for the stm32f chips this is needed. micromouseusa.com/
Has Keil mdk5 not provided a simple function?
Ok I see the advantage to the example Clive demonstrated. Though I'm not sure it will work in the end as we do need to write to flash during execution as well as an init structure. I have yet to try it because I can not make any flash write functions work. Very difficult to get an idea of how all of this works if you can not see any real examples.
The EEprom emulation is starting to sound like an over kill.
"The application requires two Flash memory sectors of identical size allocated to non-volatile data:one that is initially erased, and offers byte-by-byte programmability; the other that is ready to take over when the former sector needs to be garbage-collected. A header field that occupies the first half word (16-bit) of each sector indicates the sector status. Each of these sectors is considered as a page."
Did that not just cut of 32k of my available space? I still hope to avoid this as best I can.
The way we intend to use EEPROM is wring an init structure and saving tokens.
line one (16 bytes) contains the structure the next few lines (16 bytes each) hold token data. Each use will store a token. This needs to be available for consecutive uses. Wait times for storing and read are not an importance. Using any type of battery or external eeprom will allow this to be erased/copied cheating the intention.
If I understand the eeprom emulation correctly it will need to be at sector 0 first 6k. then it takes 2 more sectors for eeprom. Still unclear but somehow the actual code will use an API to write to the manager in sector 0 and work as EEPORM. Assuming not via i2c to itself?
I'd like something more like what Clive has shown that would allow writing directly from the code itself. After unlocking the flash I can read very easily with read = *((uint16_t *) FLASH_PAGE); I understand writing is more complicated but none of the examples or functions work. The executed code in sector 0, should be able able to write to sector 2 with the needed unlocks in place with first an erase function. if(HAL_FLASH_Unlock()!=HAL_OK) FLASH_PageErase(0x0800C000); FLASH->CR = 0; if(HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, 0x0800C000, 0x01010101) != HAL_OK) //error
Ok I have it working now, much clearer picture. I see now I'll need some type of shadow array to hold the writes as I progress thru the code as I can only write a page at a time. Using my last sector would be far to wasteful and using the first has that bootloader issue that can be addressed but is a pain to deal with at first.
I just want to rule out the hole in the middle possibility?
code fake eeprom or nvram code code code...
Is there anyway possibly of using IROM so that the code can be split up to have a hole in the middle for this fake nvram.
Use a scatter file that puts the vector/reset stuff low in flash, leaves space for your configuration flash area and add a section for everything else past the configuration flash area you want to use.
Along these lines?
LR_IROM1 0x08000000 0x00804000 { ; vector/reset ER_IROM1 0x08000000 0x08004000 { ; *.o (RESET, +First) *(InRoot$Sections) .ANY (+RO) } RW_IRAM1 0x08004000 0x08008000 { ; eeprom area .ANY (+RW +ZI) } }
LR_IROM2 0x08008000 0x08100000 { ER_IROM2 0x08008000 0x08100000 { ; remaining of code.. .ANY (+RO) } }
Hope this is more readable.
LR_IROM1 0x08000000 0x00804000 { ; vector/reset
ER_IROM1 0x08000000 0x08004000 { ;
*.o (RESET, +First)
*(InRoot$Sections)
.ANY (+RO)
}
RW_IRAM1 0x08004000 0x08004000 { ; eeprom area
.ANY (+RW +ZI)
LR_IROM2 0x08004000 0x08100000 {
ER_IROM2 0x08004000 0x08100000 { ; remaing of code..
This is something that you will understand best if you do it yourself. You should try to build with that scatter file and see what fails. You have a general idea of how to use the scatter file to do what you want to do, but have a few errors that you will go "why was I thinking that would work" once you figure them out.
One hint: +RW variables cannot go into flash. // this is actually more than 1 hint