cancel
Showing results for 
Search instead for 
Did you mean: 

Bin file and memory in microcontroler are not identical after launch

ANauz.1
Senior

Hello,

I have a project where I am trying to check flash memory by calculating the CRC32 of it and compare it to the CRC32 of the generated .bin file to verify memory corruption. As the CRC32 was not ok, I realize that the memory in the generated .bin file and in the microcontroler was not exactly the same.

I'm working on a F407 STM32 µC. After launching the debugger, the 2 32bits at memory address 0x0800 0188 are set  to 0xFFFFFFFF while in the .bin file, they are equal to 0x00000000.

0x0188 is the length of the g_pfnVectors. So from what I understand 0x0800 0188, it is the address of the Default_Handler. Not sure of that. And I do not understand why it is set to 0x00000000 in the .bin file and set to 0xFFFFFFFF after launch. 

I have check with STM32CubeProgrammer, the 2 32bits @0x0800 0188 are equal to 0x00000000 after flashing the bin file. It is the launch that change the value to 0xFFFFFFFF.

Is there a way to avoid this? Either make the data in flash stay at 0x0000 0000 are having 0xFFFF FFFF in the binary file?

I would be happy to have any explanation one the behavior.

Thank you

Antoine

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
ANauz.1
Senior

So,

I finally found a solution.

When generating the .bin file from the HEX file, I added the "“—gap-fill=0xFF" option.

Empty data are set to 0xFF, and bin, hex and elf file are the same.

View solution in original post

3 REPLIES 3

Are you writing the .BIN file, or the ELF or HEX file?

The latter can be sparse, and the padding of voids will be 0xFF which is the default for erased Flash in the situation. 

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
ANauz.1
Senior

Hello,

You point me one thing:

With STM32CubeProgrammer, I am writing the .bin file. And as I said, the data is "correct" equal to 0x0000 0000

But when launching, it is the .elf file that is used.

And in the HEX file there is a line that look like end of g_pfnVectors that is "shorter than other". Could be an area uninitialized?!

Is there a way to force the data in HEX to be set to 0? In the LD file, I tried with "FILL(0x00000000) in the .isr_vector section but it do not change anything.

Maybe I am not filling the correct area. Do you know what is the area to fill juste after the g_pnfVectors? Or maybe I'm in the correct area but not using correctly the FILL command.

I have

 

SECTIONS
{
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    FILL(0x00000000)
    . = ALIGN(8);
  } > FLASH
[...]

 

 

Thank you for your help

 

 

ANauz.1
Senior

So,

I finally found a solution.

When generating the .bin file from the HEX file, I added the "“—gap-fill=0xFF" option.

Empty data are set to 0xFF, and bin, hex and elf file are the same.