Bootloader and distance reprogramming

[Steven Bébin]

Hello,

I program on the NUCLEO-144 STM32F767ZI board and I have been facing a problem for over a week.

In FLASH memory, I have 3 programs located at specific addresses:

- A bootloader which allows to start on the main programmer or reprogramming program.

- A main program that has several functions like http server, tcp server, usart ...

- A reprogramming program that distance reprograms the stm32 card. The operation is basic, I send a binary file to an http server, then I put at the place of the main program.

When I reprogram with a basic program (for example: to light an LED) everything works. on the other side when I reprogram with a big program (for example: my actual main program) it does not work. The stm32 seems to hang somewhere and I do not know where. I have already tried to remove all the interruptions before jump, it does not change anything.

On the front line of all my programs, I have the "SCB-> VTOR" which points to current address.

Here my bootloader code :

#include "stm32f7xx_hal.h"
 
	#define REPROGRAMMATION_ADDRESS 0x08020000
 
	#define FLASH_MEM1_FIRST_ADDRESS	 0x08040000
 
	void JumpInProgram(uint32_t address);
	
	typedef void (*pFunction)(void);
 
	pFunction Jump_To_Application;
 
int main(void) 
{
	SCB->VTOR = 0x8000000;
	if((*(uint32_t*)0x80C0000 == 1) JumpInProgram(REPROGRAMMATION_ADDRESS); // if variable locaded "0x80C0000" is equal to 1 go to reprogrammation program
	else JumpInProgram(FLASH_MEM1_FIRST_ADDRESS); // else principal program
}
 
void JumpInProgram(uint32_t address) 
{
	uint32_t JumpAddress = *(__IO uint32_t*)(address + 4);
	pFunction Jump = (pFunction)JumpAddress;
	__set_MSP(*(__IO uint32_t*)address);
	Jump();
}

Here my main fonction in principal program for example :

int main(void)
{
	SCB->VTOR = 0x8040000;
 HAL_Init(); 
 SystemClock_Config();
	
	MX_GPIO_Init();
	
	MX_TIM4_Init();
	
 MX_USART1_UART_Init();
	MX_USART2_UART_Init();
	MX_USART3_UART_Init();	
	
	HAL_TIM_Base_Start_IT(&htim4);
	HAL_UART_Receive_IT(&huart3, donneetic, 1); 
	HAL_UART_Receive_IT(&huart1, donneerf, 1); 
	
 osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, configMINIMAL_STACK_SIZE); 
 defaultTaskHandle = osThreadCreate(osThread(defaultTask), NULL);
	
 osKernelStart(); 
}

Hoping you can help me, thank you

[Tesla DeLorean]

>> The stm32 seems to hang somewhere and I do not know where.

That's why we have debuggers, and instrument code so we know where it goes, the flow, and where it is stuck.

Make sure things like HardFault_Handler() and Error_Handler() output actionable data, rather than spin in a while(1) loop.

Identify all other dead locking or infinite loops, or those lacking timeouts.

Get a UART up, or GPIO, so you can provide information, or check-points, to pin down progress without a debugger attached.

When stuck, stop in the debugger, and review a) where it is in all your code, and b) the state of memory/peripherals

Don't transfer control from interrupt context (ie EXTI, SysTick, etc). Callbacks are executed in interrupt context.

Don't transfer control from an RTOS with User/System execution states, in User or Interrupt contexts.

[Steven Bébin]

Thank you very much for your answer !

Unfortunately, I use the debugger to see where the program block. I also use GPIOs as control points to help. But despite that, I can not find the problem! I will not say that the problems are random, but almost! One day, the program was stuck in the msp_init() function and the day after it was blocked on the systick function.

I did not understand the last two lines.

While searching the web, people were talking about initializing properly before making the jump. But I do not know how to do it. Should devices, clocks, and other be uninitialized before jumping?

Sorry to appear a little lost, but I am clearly

[Tesla DeLorean]

>>While searching the web, people were talking about initializing properly before making the jump. But I do not know how to do it. Should devices, clocks, and other be uninitialized before jumping?

You have to define that contract between both sides, and implement it. Most of ST's boilerplate code assumes a blank-slate, reset-like, starting point

If your loader initializes all the clocks, and PLLs, no need to do it again in the app.

You should turn off all interrupt sources at each peripheral, the RAM and structures used by the loader aren't passed to the app, and will be placed in different memory by the linker. Identify the peripherals your loader is bring up, and get them into a safe state. You don't need to DeInit(), just be conscious to turn off the bits in the ISR registers. Using __disable_irq() really side steps doing things properly/mindfully.

When the app starts, none of it's RAM has been initialized, you don't want the loader SysTick firing. It might contain random stuff, and be mapped entirely differently.

Make sure your app code doesn't have any expectations about the HW or peripherals being in a RESET state

>>I did not understand the last two lines.

The processor maintains state, as does the NVIC, you need interrupts/handlers to unwind. If you transfer control from one premption level, you're never going to get anything at or below that level again.

 SystemInit() usually sets SCB->VTOR, ST's code is dumb, I let the linker fix up using the __vectors symbol

[Steven Bébin]

Hello !

I found the origin of the problem, but I do not know how to explain it. In my main program, I have a lot of global variables (variables used throughout the program). Approximately, I can not really be precise, I have 80kb of global variables.

When I decrease this number of variables, I manage to run the program.

[Steven Bébin]

I do not understand. Sometimes it works sometimes it does not work. I use __disable_irq (); and __enable_irq (); but nothing changes.

[Steven Bébin]

After sending a new program, the boot loader sends well to the correct address. When I'm in the debugger, I arrive in a hardfault function. The problem is never the same, sometimes the program block in the Hal_init (), sometimes in the SystemClock_Config () ... I have already tried to disable all interrupts, but nothing works. When I load the program with a download directly with the Keil software, it works well. But as soon as I'm in API, it is impossible.

[Steven Bébin]

In my flash memory, my bootloader is in sector 0. I have parameters in sectors 1 and 2. My main program is located in sectors 5,6 and 7. My secondary program (reloaded by IAP) is located in sectors 8, 9 and 10. I do not use sectors 3, 4 and 11.

When I do tests, each time, I delete the secondary program so sectors 8, 9 and 10.

I do not know what went through my head, I thought, "What if I erased the sector 11 while we're there?" And well after clearing sector 11, the program was no longer blocking in the same place, the initialization was perfect, it even launched the threads. I thought it was not possible, nothing is related to my sector 11, I tried, like it works, but it seems to block further.

I'm still a beginner, but I think I'll unplug my brain this weekend, I need it.

[Mtx_ing5]

Maybe it's a basic question but do you change your linker for each application? I'm working in a bootloader for a STM32L476RE and sometimes when I don't update the linker, the MCU get stuck for a big program but it's works for a simple one.

[Steven Bébin]

Hello, thank you for your answer !

I do not know if "Linker" means the start address of the app, but if it does, I'm good. What I do not understand is that normally with a wrong starting address, no matter the application it would not work. So I must be wrong.

I use Keil as programming software. To change the starting address of the application, I modify the position of IROM1 and the size.

In any case what you tell me is interesting, I may be a small mistake from the beginning. Thank you

[Tesla DeLorean]

The GUI settings build you a scatter file (linker script) doing what you need.

The Size here is a total, not an end point, so 0xC0000 is more appropriate than 0xBFFFF

[Piranha]

Why are bootloader and reprogramming program two separate programs?

*(uint32_t*)0x80C0000 == 1

There is no need to wear flash for passing variable to bootloader. This can be done with a special region of SRAM, as hardware does not erase it at reset.

For changing bootloader/application modes there is a much better and simpler solution, which cancels all dependencies completely. I described it here:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

[Steven Bébin]

Hello, thank you for your answer !

My reprogramming program is quite large, it manages an LCD, a webserver, threads .. It's quite large that's why I really wanted to insist on having a bootloader and 2 separate programs.

What you told me is very interesting. I had never thought about it. I may not be including it in the program at the moment as this will not solve the problem, but I would see it in the future. Thank you

[Steven Bébin]

Hello everyone,

Well I advance on the problem, but I'm pretty lost. I manage to run the program download by TCP IAP. The problem is therefore "solved". However, for this to work, I have a need to boot the zone.

Let me explain, when I transmit my program under TCP IAP, it is transferred to sectors 8, 9 and 10. When I restart, it does not work.

However, when I transmit the program with the software (classic transfer), then I delete sectors 8, 9 and 10 and after I transmit my program by TCP IPA, it works!

It's very weird, I'm lost but I will continue to find the problem. Help is welcome, thank you very much.

I specify that with a normal download with the KEIL software, the same program is totally working!

[Steven Bébin]

When I send program by TCP IAP. The program starts.

I have an LCD screen with several menus. I can move in the menus, but as soon as I go in some menu, the card block.

At one point, going into a menu, I saw another menu appear, it was not the right one. So I think sometimes, instead of going to the right address of flash memory, it goes to another. I can not explain why or how. But it seems to happen.

What's odd is that I configure the SCB-VTOR well at the beginning of the program. And the program works until a moment when we come to a bug.