Problems with application, after boot loader.

[CopaCabana_ Reemer]

Hi, guys.

I've been having, a really strange problems with my project and i need anybody help.

I'm using here a microcontroller STM32H743VI revision X. I made a custom bootloader with USB MSC and the problem is, work everything correct with the boot, i can Errase the internal Flash and jump to the application, however when i'm run my application some peripherals such as CAN and Uart,loses the original parameters and stop work correctly. I don't now if the problem is the boot or the application.

There is bellow, my jump code:

void DeInit_ALL(void)
{
	HAL_Delay(2000);  //To "lock" boot screen, avoiding flash effect"
	showScreenBootloader(0);
 
	MX_TIM17_Stop();
 
	//Disable CPU L1 cache before jumping to the QSPI code execution
	SCB_DisableICache();
	SCB_DisableDCache();
 
	//Disable Systick interrupt
	SysTick->CTRL = 0;
}
 
 
void Jump_APP(void)
{
	uint32_t JumpAddress;
	pFunction Jump_To_Application;
 
	#ifdef __UART_DEBUG
	my_printf("JUMP!");
	#endif
 
	FLASH_If_FlashUnlock();
	DeInit_ALL();                                                  
 
	JumpAddress = (*(__IO uint32_t*)APPLICATION_ADDRESS);
	if ((JumpAddress & 0x2FFE0000) == 0x20020000)                         //Flash Status Check
	{
		/* Manipulação do salto para Stack Pointer */
		JumpAddress = *(__IO uint32_t*)(APPLICATION_ADDRESS + 4);
		Jump_To_Application = (pFunction)JumpAddress;
 
	    HAL_FLASH_Lock();
 
		HAL_RCC_DeInit();                                                    
 
		SysTick->CTRL=0;													 
		SysTick->LOAD=0;												
		SysTick->VAL=0;													
 
 
		__set_MSP(*(__IO uint32_t*)APPLICATION_ADDRESS);
		Jump_To_Application();
	}
}

I reallocate the interrupt vector (SCB->VTOR) in my application, to APPLICATION_ADDRESS.

I need to DeInit any more parameters? Is this behavior normal? This issue have fixe?

Best regards.

[Bob S]

What you you mean "looses the original parameters"? Do you mean that your bootloader enables and configures the UART and CAN ports, and then when your main application runs they have a different configuration and/or they stop working? Or does the bootloader ignore these peripherals and only your application attempts to configure/use them, and that the UART/CAN ports work for a while in your main application but then stop working?

Your DeInit_All() does not disable interrupts for any UART/CAN port, so if the bootloader is using them they remain enabled when your application starts.

[Tesla DeLorean]

Can you perhaps use a debugger? Query the peripheral states?

Interrupting via USB, CAN, USART, etc? RAM context going to be completely different from one to the other.

Check the range of SP that might actually be used.

[CopaCabana_ Reemer]

@Bob S​  Thanks for your answer, my bootloader ignore these peripherals and only my application configure/use them. But when i start the application without a bootloader everything works fine only when i put bootloader + application, this peripherals stop to work, so it isn't the code.

Let me explain better what it is "stop to work", watching with a oscilloscope, the application send the command, but never complete the communication, appearing error of baud rate but I could not come to any conclusions yet.

[CopaCabana_ Reemer]

@Community member​ Thanks for your answer. I will check the range of SP, is a good point. My difficult with use the debugger is that i can't debug when i use the Bootloader + Application, and that is the only condition witch there is this issue. I'm using true Studio for develop, if you know a way to debug with bootloader, please let me know too.

[Tesla DeLorean]

Several threads here in the last day or so suggest TrueStudio can take TWO .elf files/symbols as input so you can see both.

I might be able to load two in Keil, via a debug script, but I usually pick one or the other, and know my way around the one without code well enough I can figure things out. The .MAP file contains a lot of detail.

The debugger should permit probing of peripheral space regardless of programming being debugged.

You can also write routines to dump peripherals out, as well as add in enough instrumentation so the thing can report its location, and operating conditions.

Don't transfer control from an interrupt or callback.

Don't transfer from an RTOS.

Be aware of what resources your loader is bringing up.

Perhaps bisect that code to see what particular areas are giving headaches.

You don't have to deinit peripherals and clocks. A smart app will understand that the clocks, plls, and flash states are already "ready-to-run"

Similarly USART, CAN and USB can be left alone, for the most part, and then you can pass existing context across the transition. You can protect memory areas in RAM via the linker script, or use BKPRAM, or whatever to pass context.

[CopaCabana_ Reemer]

Hello Clive, after some tests. So far what I could identify was a considerable error in the time of the UART baudrate, 109us to 9600bps being that it should be 104us, with the microcontroller running at 400MHz without external crystal.

Testing at 4MHz (internal oscillator - CSI), the error reduced to 105.5us and started working with and without the bootloader executed by the internal flash.

You have any idea to fix that, without put a external crystal??

[Tesla DeLorean]

Several people have complained about the trim values for the internal clocks.

[Tesla DeLorean]

https://community.st.com/s/question/0D50X0000B41tlASQQ/stm32h743-hsi-frequency-waaaayyy-off