Problem Using Jump_To_Application() in IAP Bootloader

[Seyed]

Hello ST community!

I'm using a stm32F417VGT6 to perform an IAP in Keil IDE.

in the bootloader, using the binary file on a SD card, I read executed binary program and write it on flash memory. then i use Jump_To_Application() to start the new app. Everything works just fine and we've got no problems.

this process is all OK with 4KB and 25KB binary files. BUT when i try to load Heavier binary files like 112KB or 500KB, the MCU resets and no jumping happens. after this reset we start from begining of bootloader.

I've double checked the MCU flash with ST-LINK Utility and my binary file has been written correctly on the correct address.

and sadly, there's no way to debug because the MCU is not on the bootloader code anymore.

as you may have noticed, this is suspicious. as far as i know jumping to a new program has nothing to do with size of that program.

and here's the set of codes i use to perform the jump:

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

                  Jump_To_Application = (pFunction) JumpAddress;

                  Jump_To_Application();  

and ofcourse, I do disable almost any peripheral and interrupt that I've enabled inside the bootloader.

I would be appreciated if you share your solutions.

or if you needed more details, feel free to ask.

[MM..1]

Use bootloader as prestarted application isnt good. IAP is simpler use in reboot mode. EXAMPLE:

1. normal power up or IWDG ... botloader main start with if normal power jump to aplication
2. press something or jumper on power ... application reboot with WWDG or check gpio jumper and bootloader detect it and do flash from sd card on end reboot by IWDG .. start app in point 1

As you can see jumping to application is on bootloader start without init any problem

[Seyed]

Hello and thank you for your help

as i mentioned, there is no problem with light weight binary files. I'm looking for the problem and i can't change the way i load new applications.

[MM..1]

Ok then you need debug and locate point what reset. Why you don’t debug ? How big parts you load from SDCARD and FLASH at once ? Simply place breakpoint to end flashing before deinit periph and IRQ usw...
And I recomm RESET because start app is more more better with clean envi ...

[Seyed]

well i didn't quite understand your words but these are answers to your questions :

1- I flash 1024 byte each time

2- as I said ,I've double checked the MCU flash with ST-LINK Utility and my binary file has been written correctly on the correct address.

3- and also, there's no way to debug because when we jump, we're on 0x8008000. the MCU is not on the bootloader code anymore.

[MM..1]

Your point 3 is right when your code crash RESET after jumping. But how you create your big bin code? For example if KEIL is used then you can configure KEIL to flash and run this big code for debug it. (stlink used instead SDCARD)

But back to your trouble you need check if crash is in bootloader before jumping or after.

And maybe good is show here main code start part from 500kB build ...

[Piranha]

> there's no way to debug because when we jump, we're on 0x8008000. the MCU is not on the bootloader code anymore

If the bootloader and jump works OK, then debug the code after the jump - the application!

[Seyed]

Hello Piranha and thank you for your help

thanks to you, I've figured out that we could debug the application, using the same project we used to create the application.

I'm gonna debug the code and surely share the result here.

regards

[Seyed]

Hi

I create the binary file using the executed HEX file and the hex2bin.exe tool

and thanks to you and piranha now I can debug the application. gonna see what i'm going to find out in debug

[Seyed]

well, the debugging worked and i found which part is causing the reset.

first of all, after the jump i can see we enter the main() of the application. HAL_Init() also runs. but in SystemClock_Config() in file stm32f4xx_hal_rcc.c line 549 these lines occur and HAL_ERROR is executed :

       if((READ_BIT(pll_config, RCC_PLLCFGR_PLLSRC) != RCC_OscInitStruct->PLL.PLLSource) ||

          (READ_BIT(pll_config, RCC_PLLCFGR_PLLM) != RCC_OscInitStruct->PLL.PLLM) ||

          (READ_BIT(pll_config, RCC_PLLCFGR_PLLN) != RCC_OscInitStruct->PLL.PLLN) ||

          (READ_BIT(pll_config, RCC_PLLCFGR_PLLP) != RCC_OscInitStruct->PLL.PLLP) ||

          (READ_BIT(pll_config, RCC_PLLCFGR_PLLQ) != RCC_OscInitStruct->PLL.PLLQ))

       {

         return HAL_ERROR;

       }

and this error, calls the Error_Handler() and inside this handler, we got HAL_NVIC_SystemReset().

Now the subject has been changed.

I think (and maybe I know) the problem happend because of the conflict of the "bootloader" RCC settings and "application" RCC settings. and I tried to reset any RCC config that I made inside the bootloader, before I jump to application. all I found was to disable the systick

SysTick->CTRL = 0;

any solutions? did I even found the problem and should I do anything with RCC ?

if yes, what has to be done?