stm32H7, HAL_Deinit() causes core stall

[iTTy]

Hi there, I'm fixing the jump function from my custom bootloader to the application, below the code:

 

 

static void __inline__ CheckAPPjumpRESET(void)
{
	/*.-.-.| Local variables: |.-.-.*/
	u32t uiI = 0;

	/*.-.-.| Execution: |.-.-.*/
	if(GetRESETkey() != RESET_DRV_APP_KEY)	{	;	}
	else	{
		// RESET_DRV_APP_KEY found: jump to app!
		SetRESETkey(RESET_DRV_BTL_KEY);
		__disable_irq();							// Disable all interrupts
		SysTick->CTRL = 0;							// Disable Systick timer
		HAL_RCC_DeInit();							// Set the clock to the default state

		// Clear Interrupt Enable Register & Interrupt Pending Registers:
		for (uiI = 0; uiI < 8; uiI++)
		{
			NVIC->ICER[uiI]=0xFFFFFFFF;
			NVIC->ICPR[uiI]=0xFFFFFFFF;
		}

		SCB_CleanDCache();							// Clean Data Cache
		SCB_DisableDCache();						// Disable Data Cache
		SCB_DisableICache();						// Disable Instruction Cache

		HAL_MPU_Disable();							// Disable MPU

		HAL_DeInit();

		__enable_irq();								// Re-enable all interrupts

		DoAPPjumpRESET(FLASH_INT_M7_APP_START_ADR);
	}

}

 

 

My Bootloader is running only on the M7 core, while the application uses both of them; since I'm having trouble in peripheral initialization in the application I tried to reset all of them in the jumping function using HAL_Deinit() function. Doing this, after the jump the M4 core is stalling: it seems it is not running but I' dont have an Hard Fault...

Has anyone some idea?

Thanks in advance,

iTTy

[TDK]

Debug the code on startup and see why/where the M4 stalls. You should be able to debug both cores simultaneously and step through startup.

As for why it's failing--this is going to come down to what the M4 core does on startup and we have little insight into that. There's no fundamental reason things can't work the way you want. I assume the M4 core is stopped while the bootloader is running and it's started again by the M7 core during startup? That would be the proper way to handle things.

[iTTy]

Hi @TDK ,

thanks for your reply and sorry for my delay.

Of coarse, the M4 core remains stopped during the Bootloader execution, and the jump toward the application is executed after a system reset.

I tried to debug the application startup, but using the IDE and the STlink/Segger probe seems to lead to different behaviors...

Anyway, I've the feeling that The M4 core remains in its ResetHandler function...

I'm still working on it!