address 0x8000188-0x800018F differs based on programming mode

[Adam3]

Dear all,

I am writing a bootloader and I experienced that the calculated CRC on the binary is different If I load the fw with cube IDE versus cube programmer. I use STM32F405.

This happens too if I make the compairement on the bootloader programme too.
The difference is present on 8 bytes after the interrupt vector table.

For example in this case: (based on the .map file's information) 
- the bootloader programme starts at 0x800.0000 and
- the .isr_vector is 392 byte length which is 0x188.   
- the .text region starts at 0x800.0190
- So memory 0x800.0188-0x800.018F is unused if i seems well.

I attach the screenshots of these compairements in cube programmer.
The difference is independent of whether I compare the mcu with the .elf or the .bin file.
If I load the programme with the cube programmer, the difference disappears.

I do not know why there is the difference. Could anybody tell me?

The linker file is unmodified in the case of the bootloader:

 

 

/* Memories definition */
MEMORY
{
 CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
 FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 48K
}

/* Sections */
SECTIONS
{
 /* The startup code into "FLASH" Rom type memory */
 .isr_vector :
 {
 . = ALIGN(4);
 KEEP(*(.isr_vector)) /* Startup code */
 . = ALIGN(4);
 } >FLASH

 /* The program code and other data into "FLASH" Rom type memory */
 .text :
 {
 . = ALIGN(4);
 *(.text) /* .text sections (code) */
 *(.text*) /* .text* sections (code) */
 *(.glue_7) /* glue arm to thumb code */
 *(.glue_7t) /* glue thumb to arm code */
 *(.eh_frame)

 KEEP (*(.init))
 KEEP (*(.fini))

 . = ALIGN(4);
 _etext = .; /* define a global symbols at end of code */
 } >FLASH

 

Thanks in advance
Adam

[Sarra.S]

Hello @Adam3, welcome to ST Community 

You have to ensure that your code is 32-bit aligned before calling the CRC calculation to avoid automatic padding 

Please note that STM32CubeProgrammer uses automatic padding by zeros when the code is not word aligned!

[Pavel A.]

@Adam3 Can you clarify? Do you create a .bin file from .elf and calculate checksum on the .bin file before burning on the board, or you calculate the checksum on the board, after burning?  The holes that do not result due to ALIGN() statements in the linker script, and any padding, can be filled by 0 or FF, depending on the program used. The filler value for ALIGN can be specified in the script TL;DR.

From the link script it isn't clear why .text begins at 16 bytes alignment. This isn't a problem anyway.

If you create a .bin file first, all holes will be already filled by either 0 or FF, and it won't give you surprises.

[Adam3]

Dear Pavel, and Sarra

Thank you for your reply. I can clarify.
I decided to calculate a CRC on the application's .bin file. I made it with a post build executed power shell scrip file.
In the bootloader I calculated the crc on the same application which has loaded into the mcu.
- when the application has loaded with cube programmer, the crc calculated with the .ps1 file was the same than the calculated by the mcu.
- when the application was loaded with the cube IDE they were different.

I found the reason, but I do not know why it is being.
I made a comparison the in the case of the bootloader.bin file, and I found the same problem. Now I examine the bootloader, because it produces the same problem and it is simpler.

- In the .bin files the unused 8 bytes after the interrupt vector table are filled with 0.
I attach an image from this .bin file which made with a hex editor.
The bootloader is aligned to 0x800.0000 so it is quite sure aligned.

When I programmed the flash from the CUBE IDE the CRC did not match. After this I read out the flash of the mcu with the cude programmer and there I found these 8 bytes are filled with 0xff. 0xff is the values after the flash has been cleared. So this made the difference in the CRC.
I think the IDE uses the .elf file for programming instead of .bin.

Do you need any more information?