STM32 bin file at address 0x4

[JFELI.13]

If you need to understand why it's important, this is a part of bootloader:

#define PROG2_AD 0x2B200
#define PROG1_AD 0x400
#define PROG1_VECT_AD 0x300
#define PROG2_VECT_AD 0x200
...

pg1_Present=FALSE;
x4=PROG1_VECT_AD+4;
ptr=(unsigned long *)x4;
y4=*ptr-1; 

switch (y4)
{
case PROG1_AD:
pg1_Present=TRUE;
pgStop=PROG2_AD-1;
pg1_End=Flash_FindProgEnd(PROG1_VECT_AD);
pg_Size = pg1_End - PROG1_AD;
pg1_SizeKo=pg_Size / 1024;
pg1_PercentUse =(char)((pg_Size * 100) / (pgStop - PROG1_AD));
break;

default: 
break;
}

pg2_Present=FALSE;
x4=PROG2_VECT_AD+4;
ptr=(unsigned long *)x4;
y4=*ptr-1; 

switch (y4)
{
case PROG2_AD:
case 0x35B28: // if I add this line it will work at this time
pg2_Present=TRUE;
pgStop=BOOTLOADER_AD - 1;;
pg2_End=Flash_FindProgEnd(PROG2_VECT_AD);
pg_Size = pg2_End - PROG2_AD;
pg2_SizeKo=pg_Size / 1024;
pg2_PercentUse =(char)((pg_Size * 100) / (pgStop - PROG2_AD));
break;

default: // no soft
break;
}
IEE_ProgVect=IEEPROM_READ32(IEE_PGACTIVE_VECT); 

[Andrew Neil]

What makes you think it should be 0x2B200 ?

[Tesla DeLorean]

You don't

You load the value stored at that address as a function pointer.

You don't jump to the 0x08000004 address, but what's in it, ie indirectly

The address there is ODD because it's pointing at 16-bit Thumb Code. Check the address of Reset_Handler in the .MAP file

But why the linker is creating the code behind it as if it's at ZERO is another question. You should double check you linker script (.LD)

[Tesla DeLorean]

The value there is determined by the LINKER, based on where the code ends up fitting, per the LINKER SCRIPT

Might help to study those topics, along with how the Cortex-Mx cores function,especially when it comes to the Vector Table.

ARM has the TRM, ST has the Programming Manuals, Joseph Yiu has a number of books on the Cortex-M parts

[JFELI.13]

OK, this therefore means that I cannot really know the address to which the bootloader wants to jump, 0x4 content depends on the programming context...

[TDK]

You don't know the exact address to jump to, true, but you know where to look for it. That is standard procedure. For example, look at example code for jumping to the bootloader. It does not jump to an address, but rather an address read from a particular memory location.

https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/ta-p/49424

[Tesla DeLorean · Accepted solution]

This seems unnecessarily complex and laboured.

Typically you build an app for a specific address, via the linker. The Vector Table is part of the image. The SystemInit() code can set the address of SCB->VTOR based on the symbol the linker assigns the table in a given build. The application should and can be agnostic to the location it's built to live.

You put the Loader at 0x08000000, App1 at 0x08008000, App2 at 0x08020000, or however they need to space related to the size of the respective images and the space available in the FLASH. These BASE addresses are the only thing the Loader really needs to know.

The Vector Table contains the entry point (Reset_Handler) and you hand off control there.

It's also not hard to embedded length of image data in there too if need be.

Most of the CM3 from ST will want the vector table to live at a 512-byte boundary, but this depends on the size and total number of vectors, rounded to the next power of 2

The LINKER is DESIGNED to compute and solve placement problems, and fixate addresses, it can use and generate symbols, let it do the hard work by doing it's job.