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 thx, one thing before I start this journey. Is this example only going to get me the 80 bytes? I read the RTC only had 80 and the other (more battery drain) had more.
The RTC has 80 bytes of backup registers, as I recall.
The BKPRAM (NVRAM) has 4KB
hmm, same errors as my post on 22-Aug-2017 15:28
Many definitions missing. I tried to included #include "stm322xg_eval.h" but it is not found and also not included in the example download.
Again, what firmware library are you using? CLEARLY (at least to me) you are not using the STM32F2xx_StdPeriph_Lib. Your examples that you have posted are expecting you to be using that firmware library. The reason you are getting errors EVERY TIME you build your example code is because it is making references to the STM32F2xx_StdPeriph_Lib and you are not actually using that library.
The library is stm32f2xx_hal
After destruction with the team and considering nvram/i2c, eeprom, flash. We decided to go with flash. Eeprom emulation or may what "Clive One" suggested. Can anyone suggest a way to see the flash after I do a test write? A visual debug would be essential in troubleshooting.
oops / discussion - but sometimes does feel like destruction.
That's what the debugger is for!
Please read the manual: http://www.keil.com/support/man/docs/uv4/uv4_db_dbg_memwin.htm
I found a project of some help.
github.com/.../eepromConfig.h
It compiles all but he flash erase.
flashErase.NbPages=1;//error no member flashErase.Banks = FLASH_BANK_1; flashErase.PageAddress = _EEPROM_FLASH_PAGE_ADDRESS; //error no member flashErase.TypeErase = FLASH_TYPEERASE_PAGES;
and FLASH_TYPEERASE_PAGES does no exist.
flashErase has; voltageRange nbSectors sector
guesssing nbSectors/sectors and nbPages/PageAddress interchangeable? and how can I find the missing define FLASH_TYPEERASE_PAGES what would I use for a voltageRange?
ok got it all flashErase.NbSectors=1; flashErase.Banks = FLASH_BANK_1; flashErase.Sector = _EEPROM_FLASH_PAGE_ADDRESS; flashErase.TypeErase = FLASH_TYPEERASE_SECTORS;
Right I forgot this Keil had a rather useful debugger, thx.
Thank you. The Flash solution is a very good choice (as Clive suggested very early). Even better than the EEPROM. Good Luck.
forget all you heard about EEPROM. although not always true EEPROM has become to mean "serial storage" the flash is accessible parallel.
remember you can tot set a bit in flash, only clear it
bad code but shows the principle
struct flashthinh unsigned char mark = o unsigned char unsigned char
to write scan the structures till you find mark =0xff write there
to read scan the structures till you find mark =0xff back up one and read
The STM32 Flash arrays have parity/haming bits associated with them, they are write-once, so you can't really incrementally knock one bits down.
The L family parts supposedly use "EEPROM", the erased state is zero (0x00), but this could just be FLASH with an inverter on the data bus. The block diagrams and slide decks really don't given much fabrication detail.
Typically NAND FLASH accesses like a block storage device. NOR FLASH accesses like random-access memory, and you can execute from it.
thx for all the advice but I'll have to start somewhere. Thus far that eeprom emulation code in my github link above helps. but few this confusing me yet.
flashErase.VoltageRange = FLASH_VOLTAGE_RANGE_4;//1,2,3,4.. Where do I look this up. I'm not finding this in the data sheet.
I can read in words (ffffffff=4294967295) so for so good and reading from my data area I do see the correct values as shown in the debugger.
writing I can not do. Per the code I sampled from no data is written. Also in the debug I can not change the memory outside my data area, I get an error. Cannot access Memory Internal command error
Do I need to enable something in the RTE?
thx for all the advice but I'll have to start somewhere. Thus far that eeprom emulation code in my github link above helps. but few this confusing me yet.>/i>
You also need to know how to move forward. I thought you did. You said you were going to go with the approach Clive proposed and use the Flash. I thought that was a very appropriate idea which started with him stating "I would avoid the idea of EEPROM emulation completely". The whole concept of the EEPROM emulation was making it very difficult for you to move forward. It was clear that it was not helping you to move forward. It was keeping you stuck on something that was just not appropriate for you to be spending time on. It was fairly clear that what Clive suggested was most likely a very good way for you to go forward. You finally said that you wanted to go with what Clive presented (NO EEPROM) which seemed like progress. Now you are back to saying that starting from EEPROM emulation code as a starting point is helping you!
Moving forward is a few steps a way. As I said I need to start with a few things to understand how all this works. This example I found shows things pretty well and got me a little further. I still "think" Clive has a good idea but what do I know? This is all new to me, so whatever works out of the box is going to fundamentally assist in learning the basics. Like the debugger.
I believe I now understand things a bit better. After studding and playing with the emulated eeprom it is becoming clear this needs to be organized upfront. So I can not just add these functions in my existing code and the code area needs to be managed. Since I plan to use a DFU bootlaoder this is only going to make thing a lot more confusing.
So in looking at this I think the flash emulation needs to be loaded in to the first sector. Kind of like a bootloader? If so that is more then I need and just going to complicate things.
Normally when I write my application it starts writing at 0x08000000, and I would only assume it will write and grow till I hit the top flash area. I'm would not expect it to skip any sectors (i.e. 0x0800C000), maybe I'm wrong?
Using Clive's method I could just write wherever I like. Dangerous yes but not if I plan everything out well.
Am I on there right track or doing more harm then good?