Issue with FLASH_ProgramHalfWord Function on STM32F103RET6

[Hossein Haji]

Hello everyone,

I hope you're all doing well.

I'm currently working on a project with the STM32F103RET6, and I've encountered an issue when writing data to a page of Flash memory. I'm using the FLASH_ProgramHalfWord function to write half-word data. While this function works correctly about 90% of the time, occasionally it does not return FLASH_COMPLETE.

To resolve the problem, I find that I need to erase the entire page. If I don't perform the page erase, the issue persists.

The device operates on battery power and initializes from scratch each time it is used.

Has anyone experienced a similar problem or have suggestions on how to address this issue? Any insights or advice would be greatly appreciated.

Thank you!

[STOne-32]

Dear @Hossein Haji ,

is that possible to know on which page @ address this is happening. Is it on particular page ? Particular Address . And how many devices having such behavior .

It might happen that the Page exceeded that number of recycled / Erase number of our specification while using it for EEPROM emulation or storing Data which is about 10K erase cycle.  You can make a test if fresh devices and see if same behavior ?

Hope it helps ,

STOne-32

[TDK]

FLASH_Program_HalfWord isn't meant to be called directly.

Use HAL_FLASH_Program instead.

[Hossein Haji]

In our firmware, we have a memory space where we store 8-byte data records. This space ranges from page address 0x800D000 to 0x807F800, which allows us to store a total of 58,880 records. Before programming the chip, we perform a full erase, assuming that the record space should be set to 0xFF. However, we encounter an issue where the FLASH_ProgramHalfWord function does not return FLASH_COMPLETE if some data was previously written to these pages. This issue persists even after performing a full erase and programming the chip. To ensure that FLASH_ProgramHalfWord works correctly, we need to erase these record spaces again.

[Hossein Haji]

We don't use the HAL library, but I noticed that the definition of the HAL_FLASH_Program function does not include any special considerations.

[STOne-32]

Dear @Hossein Haji ,

Can you please elaborate more on this “This issue persists even after performing a full erase and programming the chip. To ensure that FLASH_ProgramHalfWord works correctly, we need to erase these record spaces again”.

in our STM32F1 series , we have flash pages of 2Kbytes each for HD density .

1) a full erase of each page should be done to have 0xFFFF - Virgin area .

2) The you can write 0x0 to each 16-bit at a time etc 

As you have 8-bytes data at a time to write . Is that possible to ensure that your software is always writing to a physical address ending by 0x0 or 0x8 and see what happens ? And avoid writing to 0x2 , 0x4 , 0x6 , 0xA , 0xC , 0xE - this is only an experiment to understand what is happening.

Hope it helps.

STOne-32

[TDK]

> We don't use the HAL library,

Perhaps show your FLASH_ProgramHalfWord function if it's not from HAL then.

> However, we encounter an issue where the FLASH_ProgramHalfWord function does not return FLASH_COMPLETE if some data was previously written to these pages.

You know you can only write data once before you have to erase, right?

It sounds like your program might be writing to those pages during programming. Ensure they aren't being used. Perhaps remove them entirely from the linker file.

Edit: Another possibility is that those pages are not written during programming, but also not erased either. In which case your program won't be able to write them. If that's the case, you'll have to do a full chip erase prior to programming or otherwise erase those pages somehow before writing. Plenty of ways to do that.

[Hossein Haji]

We use the STM32 Flash Loader Demonstrator (FLASHER-STM32) to program our STM32F103RET6 MCUs. During programming, we select "Global Erase" to ensure that all pages, especially the record space, are cleared and set to 0xFFFF.

As mentioned previously, writing to Flash pages generally works fine about 90% of the time. However, occasionally we encounter issues. To solve this, we use the FLASH_ErasePage function to erase the pages that we consider as record space.

We believe the problem occurs when the address we are writing to is not cleared and is not set to 0xFFFF. The question is, why do we get an error after selecting "Global Erase" and attempting to write to flash on the first try?

I have attached a screenshot from the STM32 Flash Loader Demonstrator that we use.