Difference between Intel hex and Stm32 Flash.

[Palikem]

Hi everybody.

I ran into a problem with my project.

As you can see in the picture, after uploading the program to uP, the content of Flash is different from the uploaded Intel hex file.

Can someone explain to me why?

Where did the data F8 B5 00 BF F8 BC 08 8C 9E 46 70 47 go?

And instead of them in Flash is FF FF FF FF.

The program was uploaded via STM32CubeProgrammer.

[Tesla DeLorean]

You're looking at the wrong bytes, the orange ones are at 0x93BC

[Palikem]

Thank you for warning.

So what does FF FF FF FF mean there?

Am I to understand that it was not overwritten with data from the Intel hex file?

[STOne-32]

Dear @Palikem ,

our Flash Technology so far is designed with the following simple principle :

Virgin flash page or sector  is 0xFF , writing or programming meaning writing 0x00 or let’s say  we write 0 in an already blank / erased cell ( 0x1) . So Writing 0xFF has no effect and only writing 0x00 matters . 

it is the opposite for EEPROM Technologies .

So here to avoid issues such as CRC wrong calculation etc.. the CubeProgrammer reads back the data from flash in the missing alignment chunk and then write them again in a row with others bytes from your Hex file .

Hope it is more clear now .

Ciao

STOne-32

[Tesla DeLorean]

.HEX can be sparse, ie have holes, the default fill pattern will be unwritten FLASH, on these architectures this is typically 0xFF, but some like the STM32L1, as I recall, the empty/erased state is zero.

.BIN are not sparse, they must describe the entire linear region, the pad bytes can be chosen, but often 0xFF due to the underlying behaviour of the FLASH, EPROM, or EEPROM technologies in play.

Also watch that some of the STM32 have different width FLASH lines, say 64 or 128-bit, and may include error-correction / parity / hamming bits, and need to be written only once and aligned. They are wide because the fetch time from the array doesn't change, and is relatively slow (think of the order of 35ns), the wide fetch can then be costed over the whole line as the cache/prefetch mechanisms hide the slowness as the words are fed into the MCU.

[Palikem]

Thanks to everyone involved for the explanation.