Jump from bootloader not working after porting the application from Keil to CubeIDE

[Svenn Dahlstrom]

I have ported my application from Keil to CubeIDE and now the bootloader (not ported and still a Keil project) is not jumping to application.
The bootloader is working fine when the application is a Keil project (for many years).

The starting point for the porting has been that the Keil project was created with CubeMX and therefore would be easy to port to CubeIDE, and it was 😊.

The new CubeIDE application is working fine when running from debug or if I rewrite the bootloader to do a jump right after an reset without initing anything.
But rewriting the bootloader is not an option since this is a product that's been in the marked for years and updates needs to work with the current bootloader. 

This is my jump function:

void start_application(void)
{
    pFunction Jump_To_Application;
    uint32_t  JumpAddress;
	
    HAL_SuspendTick();
    __disable_irq();
    HAL_UART_DeInit(&huart4);
    HAL_I2C_MspDeInit(&hi2c1);

    JumpAddress = *(__IO uint32_t*) (FLASH_APPLICTION_START_ADDRESS + 4);
    Jump_To_Application = (pFunction) JumpAddress;

    __set_MSP(*(__IO uint32_t*) (FLASH_APPLICTION_START_ADDRESS));
 
    wd_refresh();
 
    Jump_To_Application();	
}  

I have verified that the SP and VTOR is correct in the new CubeIDE project.

What else do I need to check?
What is the differences between a Keil project and a CubeIDE project that can cause this not to work?
Any feedback or ideas is appreciated. 

[Andreas Bolsch]

By "porting the application to CubeMX" you probably mean that you picked the startup code from CubeMX, too?

The startup code supplied by CubeMX initializes stack pointer, initalizes data and bss segments (probably all uncritical), calls SystemInit and main afterwards. I'd suspect that SystemInit causes the trouble, maybe it relies on reset settings in flash or clock registers. If you bootloader modified some settings there ...

[Tesla DeLorean]

Step through the call. Make sure something enables interrupts on the far side. Make sure the Linker Script reflects the new basis. Keep some UART output and existing HardFault Handler output working so you can catch that.

[Svenn Dahlstrom]

Yes, CubeMX generates the system_stm32l4xx.c file and SystemInit() function.

Application use CubeMX V6.11.1 and firmware package L4 V1.18.0

The bootloader is also a CubeMX project, but it's been generated with CubeMX 5.4.0 and firmware package L4 V1.14.0

I have compared the SystemInit() functions and the only difference is that this is added in the bootloader:

/* Reset the RCC clock configuration to the default reset state ------------*/
/* Set MSION bit */
RCC->CR |= RCC_CR_MSION;

/* Reset CFGR register */
RCC->CFGR = 0x00000000U;

/* Reset HSEON, CSSON , HSION, and PLLON bits */
RCC->CR &= 0xEAF6FFFFU;

/* Reset PLLCFGR register */
RCC->PLLCFGR = 0x00001000U;

/* Reset HSEBYP bit */
RCC->CR &= 0xFFFBFFFFU;

/* Disable all interrupts */
RCC->CIER = 0x00000000U;