I can't use function HAL_FLASH_Program to program same memory address twice

[JimEno]

When I call function HAL_FLASH_Program twice with the same Flash address, the second call is ignored. See test code below.

int8_t buffer1[16] = {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};

int8_t buffer2[16] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F};

EraseIntFlash( 0x08200000, 0x08300000 );

HAL_FLASH_Program(FLASH_TYPEPROGRAM_QUADWORD, 0X0820000, buffer1);

HAL_FLASH_Program(FLASH_TYPEPROGRAM_QUADWORD, 0X0820000, buffer2);

 

In Memory Browser, I expect:

0x08200000   03020100 07060504 0B0A0908 0F0E0D0C

But I get:

0x08200000   03020100 07060504 FFFFFFFF FFFFFFFF

What is going on? I really need this to work. Can anyone provide insight or solution or workaround?

Jim Eno

[Tesla DeLorean]

Right you get one shot per address.

The flash line contains unshown ECC bits

I think you need one larger, contiguous, buffer. Or the address needs to increase

[KnarfB]

Did you check for error codes/return values?

RM0456 Rev 3:

7.3.7 Flash main memory programming sequences
The Flash memory is programmed 137 bits at a time (128-bit data + 9 bits ECC).
Programming in a previously programmed address is not allowed except if the data to write
is full zero, and any attempt sets the PROGERR flag ...

hth

KnarfB

[JimEno]

Tesla, Knarf,

Thanks for quick reply.

My actual task is to dynamically (run-time) load a 1 Mbyte data file into a reserved section of Flash using Intel Hex records from the serial port. I'm decoding the IHex records to a small 32 byte buffer and copying (attempting to) direct to Flash. Not really practical to reserve 1 MB RAM (not using a heap).

This scheme worked fine with my TI MSP432 micro. We are migrating to the STM family of micros. No, I did not thoroughly check the return values. I set a few breakpoints and got HAL_OKs.Surely there is a way to 'trick' the function into working. Can I pre-read the 16 byte block and edit ECC bits to make things look kosher? Can I disable ECC checking? Why does full zero work? I'm desperate!

Jim Eno

[TDK]

> Surely there is a way to 'trick' the function into working. Can I pre-read the 16 byte block and edit ECC bits to make things look kosher? Can I disable ECC checking? Why does full zero work?

No amount of software will get around the fundamental hardware limitations of the flash. You get one shot. STM32U5 allows a write of all 0 as a special case, which is why writing that works.

Some chips allow re-writing of flash (STM32F4 series, for example), but this one does not. It was a design choice to prevent unwanted/unexpected behavior.

You don't need to load the entire 1 MB at once. Write granularity is in 128 bit chunks. I recommended reading the flash section of the reference manual, particularly "7.3.7 Flash main memory programming sequences".

 

[JimEno]

TDK,

I attached a screenshot from STMCube.

It shows an Intel Hex file generated by the IDE. I used it to update my Application program. The result was a corrupted program. We typically used Intel Hex files with our basic BootLoader to update our code in the field. This won't work any more. What is the STM solution for updating code?

I don't mind the 16 byte block write, but preventing block re-writes with the ECC bits was a realy, realy, realy bad idea. What were you guys thinking?

Jim Eno

[TDK]

> I don't mind the 16 byte block write, but preventing block re-writes with the ECC bits was a realy, realy, realy bad idea. What were you guys thinking?

Well, let's think about it objectively. For each flash page, the ECC bits are basically a hash of the data. Writing half the flash page will change the ECC bits to a basically random value. Writing the other half would change them to a different random value. But flash can only be written once. The ECC bits are in flash, part of the same flash they hold the ECC of, they're not some in some other NVRAM that can change at will. Can't change 0s to 1s.

It's not so much an idea or decision but a logical consequence of the fundamental hardware limitations of flash.

There are chips without ECC bits that let you write flash multiple times (STM32F4 series for one) if you don't want that behavior. ECC has benefits and drawbacks

 

The real issue here is the bootloader is not writing the entire flash page at once. That is a solveable problem and will fix the limitation you're running into. Preprocessing the HEX file could work, or doing some minimal processing in code to ensure a particular flash page is only written once.