STM32F4xx Flash & CRC

[tba10596]

Posted on August 21, 2015 at 14:50

All:

We want to store some calculated values into flash, and from what I am seeing, to do that, you need to stay away from flash sector 0, because it holds the flash vector table. So, I am using sector 1 and sector 2 to store exactly the same calculated values. To do development work, I have  1. Created data similar to what will be stored. 2. Enabled CRC clock. 3. Set up a pointer to the data. 4. Reset CRC. 5. Using ''calculate block'' function, calculated the CRC-32 of the data. 6. Unlocked flash. 7. Initialized flash registers by clearing ''pending flags.'' 8. Specified start and end addresses of flash sectors #1 & #2. 9. Erased the flash using ''sector erase.''10. Programmed the flash 32-bits at a time using a for-loop (a little more than 200 values).11. Programmed the calculated CRC value into flash.12. Locked the flash.13. Read back the flash contents into a separate ''FlashData'' buffer.14. Calculated the CRC of the ''FlashData''contents.15. Compared the ''FlashData'' CRC with the CRC stored into flash. They were equal!Some comments:We are using Atollic TrueSTUDIO.It did not have a CRC example in the library, so I did find one using web search.That CRC example was almost complete - the only thing missing was the CRC-reset.I did try to work with the EEPROM emulation code, but it did not work in my environment - at one point, the Discovery board hung, and about the only way out was to exit the IDE and power cycle the board. After awhile, I stopped trying to get it to work.Any, all comments appreciated - there is more work to do before I put this into product code...Regards,Todd Anderson

[dooz]

Posted on August 26, 2015 at 10:05

I'm also programming the flash functions to store and read some data from those registers and I'm having the same problem, when I save something to flash and I power off my board then I power it up, it get hunged up and there is nothing I can do. Im using STM32F3 discovery.

[tba10596]

Posted on August 26, 2015 at 13:26

One other observation - it appears that flash sector 0 needs to be populated with the interrupt vectors on the Discovery board in order to be effective after power up or after a reset condition. Therefore, we have mapped the interrupt vectors to flash sector 0. Flash sectors 1, 2, and 3 are smaller flash sectors (16K each) and are therefore very suitable for storing multiple parameters like we are doing. Is there a way to effectively move the interrupt vectors out of flash sector 0 and still allow power up and reset behavior? There may be a point where we would like the flash to be contiguous, and right now we have some program flash memory in sector 0 and the remaining program flash memory starting at sector 3 and following. 

[tba10596]

Posted on August 26, 2015 at 15:21

I used a spare GPIO to measure the amount of time it takes to do a ''flash update.'' On my STM32F4 Discovery Board (running at full 168 MHz), it takes 460 milliseconds to do the flash update, and the bulk of that time is spent in the erase of sector 1 and sector 2.

It also looks like at least one of my interrupts is held off during the time that the flash erase is happening. It could be that because of that long time for a sector erase, it may have repercussions for those who would want to save parameters ''on-the-fly.'' In our case, the parameters being stored to flash (at least for now) are done very infrequently, and the other processes do not have to be running while a flash update is being done.Question: how does erasing a flash sector affect interrupt operation? Does it essentially block all interrupts until the flash erase is finished?

[waclawek.jan]

Posted on August 26, 2015 at 16:27

To calculate CRC, you don't need an example, and you don't need a buffer in RAM, just just need to read the fine reference manual. The whole operation is to reset it writing to appropriate control register, and then dump the data word-wise onto the data register.

> Question: how does erasing a flash sector affect interrupt operation? Does it essentially block all interrupts until the flash erase is finished?

It blocks fetches from FLASH (unless you have a STM model with dual-bank FLASH, or you run the FLASH erasing/programming function and the ISRs from RAM). Again, refer to the reference manual. You might want to consider storing config data into the battery-backuped RAM, or into external memory (FRAMs are a very nice option for this purpose). > Is there a way to effectively move the interrupt vectors out of flash sector 0 and still allow power up and reset behavior? No. Nothing from this is development-board specific. JW

[tba10596]

Posted on August 28, 2015 at 14:44https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FCRC%20computation&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=7071http://www.eevblog.com/forum/microcontrollers/stm32-crc-calculator/It turns out there needs to be an example for generating CRC32. See the above links for a huge discussion on the STM32 CRC32. 

[Tesla DeLorean]

Posted on August 28, 2015 at 18:29

It turns out there needs to be an example for generating CRC See the above links for a huge discussion on the STM32 CRC

With examples, and you know the SPL has examples of using the CRC HW, which in all honesty isn't that complex, ie enable the clock, reset the register, pump the data, read the result... There's been tons of discussions on CRC's here. [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/flash%20CRC%20integrity&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1549]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2Fflash%20CRC%20integrity&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=1549

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Programmable%20CRC%20peripheral%20in%20newer%20STM32%20devices&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE6...

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F4%20CRC%20-%20Preload%20CRC-DR&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1831]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FSTM32F4%20CRC%20-%20Preload%20CRC-DR&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=1831

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Trouble%20using%20STM32F4%27s%20CRC%20on%208%20bit%20array&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506...

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/using%20the%20CRC%20calculation%20unit%20in%20STM32F205&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B...