IAP does not jump to the desired address.

[dv.13]

Hi, I am using STM32H753VI on my own board. I was trying to programme the chip using SDCard through IAP. the program works perfectly till it erase bank1(from 0x08020000 to end of sector7 of bank1) and whole bank2.

then copies the bin file to flash. even checks for the error and gives 0 errors.

then in the jump to main section,

    /* execute the new program */

    JumpAddress = *(__IO uint32_t*) (FLASH_USER_START_ADDR + 4);

    /* Jump to user application */

    JumpToApplication = (pFunction) JumpAddress;

    /* Initialize user application's Stack Pointer */

    __set_MSP(*(__IO uint32_t*) FLASH_USER_START_ADDR);

    JumpToApplication();

where FLASH_USER_START_ADDR = 0x08020000.

but in the debug window, the value of JumpAddress shows as 0x080202AD.

and on executing JumpToApplication(); command, the device hangs. nothing happens.

can somebody help me?

[dv.13]

for binary file project,

VECT_TAB_OFFSET = 0x00020000UL  

and

in option for target section of the project, IROM1 start address is set as 0x8020000. and size is set as 0x200000.

and rest program is an usual one.

Now am I missing something?

[SNars.1852]

Try disabling all IRQs using __disable_irq() before performing jump.

Also, in the LinkerScript (.ld) file, manually edit the line :

FLASH (rx)     : ORIGIN = 0x8000000, LENGTH = 2048K

for required values of origin and length and then rebuild.

[dv.13]

tried but no success

[SNars.1852]

why dont you try flashing both different applications separately using stm32flash. There are some tutorials on how to do this.

Care must be taken that upon writing the bin at 0x08020000, the binary at 0x080000000 is not erased.

you can try if jump works with this approach.

[Tesla DeLorean]

Get a debugger that works properly.

Step INTO the jump via disassembly view. Confirm it is actually your app Reset_Handler address (will be ODD because it is THUMB code)

Check the .MAP file that things are built correctly, perhaps walk the .LST to confirm the placement and flow.

Don't have random interrupts firing, like SysTick, etc.

Disable them at the source, not with a blanket __disable_irq()

When you reach the app's Reset_Handler none of the RAM will be in an expected state (ie interrupts and peripheral instances will all be full of junk), you also shouldn't need to restart all the clocks.

Make sure you Hard Fault Handlers on BOTH side work effectively and output diagnostic data if they arrive there. Also Error Handler.

Apply debugging techniques that will help identify what is happening, and ideally have some conception of the expected/anticipated code flow and startup methods.