Programming flash memory STM32 bare metal - Page 1
Forum section: electronics / general

author: Etesla
author_rank: Regular Contributor
timestamp: October 23, 2021, 05:00:08 am
content: Hi,I'm using an stm32f072rbt6. I'm trying to write to flash memory without using the HAL libraries for the sake of the learning.The datasheet of interest is this one called reference manual here:https://www.st.com/en/microcontrollers-microprocessors/stm32f072rb.html#documentationThe pages of interest are probably pages 56, 59 and 927My first goal is just to write a value to a single flash memory address. I'm having an issue where I get stuck in some hard fault looking situation whenever I try to do so.The code that gets me here looks like this.If I use the debugger than my code gets into that fault thing after trying to execute line 96. That is my problem and I can't seem to fix it.There is mention in the datasheet that the MCU will enter the hard fault interrupt if you try to write more than a half word to a memory address, but I'm pretty sure that I am explicitly writing a half word in the code I have now... The flash SR register also doesn't give me any hints.Let me know what you guys think. Thanks in advance!

author: ataradov
author_rank: Super Contributor
timestamp: October 23, 2021, 05:17:27 am
content: You are writing a word. The line must read "*(volatile uint16_t *)0x0801f000 = toWrite".

author: timenutgoblin
author_rank: Regular Contributor
timestamp: October 23, 2021, 07:25:22 am
content: Quote from: Etesla on October 23, 2021, 05:00:08 amThe URL that you've linked to appears to be an address located on your device (local c: drive).Here is the link that I think you're referring to:https://www.st.com/resource/en/reference_manual/dm00031936-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

author: Etesla
author_rank: Regular Contributor
timestamp: October 23, 2021, 08:26:08 pm
content: ataradov that worked great. Thanks!

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 23, 2021, 08:59:18 pm
content: Quote from: Etesla on October 23, 2021, 05:00:08 amAs ataradov showed you, you were not. Well, at least you probably got confused by what "writing a half word" means. The right-hand value of the assignment was indeed 16-bit (half-word), but that doesn't matter here. What matters is that your write access was 32-bit due to dereferencing a pointer to a 32-bit integer. Maybe this is obvious to you and you just made a silly mistake (that happens to everybody!), but otherwise, I suggest learning a bit more about this if you're doing embedded programming.As to the "volatile" qualifier, this is good practice to add it here, because such an access could get optimized out by the compiler. This is a common issue, and talked about in numerous other threads, so you can look it up. Note that from tests I made with recent versions of GCC, dereferencing a pointer converted from an absolute address (integer) such as here actually does NOT get optimized out even without the volatile qualifier, but there's no guarantee about this from a standard POV, so you should use it.

author: bson
author_rank: Unknown
timestamp: October 24, 2021, 01:06:01 am
content: You probably also want to set the LOCK bit in the CR register again when you're done.Set EOP with |= on line 100.You might want to check the other bits in SR as well to make sure the write succeeded. Clear them all up front, before writing so you can detect write problems.

author: peter-h
author_rank: Super Contributor
timestamp: October 27, 2021, 02:02:50 pm
content: I posted my working code herehttps://www.eevblog.com/forum/microcontrollers/32f417-best-way-to-program-the-flash-from-ram-based-code/It is based on the Cube-generated "HAL" stuff but stripped right down.I do some extra stuff in my flashing code. For example I program the top 128k (which on the 32F4 is a single 128k block) with varying data and make sure it programs and also erases to 0xffs. If that succeeds, then I program the rest of the CPU FLASH. There isn't a whole lot of choice since an error probably means the chip is duff...