After pressing reset buton, the code turns bootloader . How can i fix it?

[G_A.]

I am writing a custom bootloader that gets hex of new user code via usart and writing on flash.

Now the system jumps to another sector and the new code works. But after presing the reset buton, the system turns bootloader .How an I fix this problem?Thanks in advance.

(Btw I tried to load this new hex code on flash via ST-Link Utility. But I did not observe same problem)

[Tesla DeLorean]

You have to handle the case in your loader. The processor is going to reset via vectors it finds at 0x00000000, and this can be either 0x1FFF????, 0x08000000 or 0x20000000 depending on the state of the BOOTx pins and thus the mapping of the memory at zero.

[G_A.]

Boot0 is connected to gnd. Also I tried to connect Boot1/Pb2 to both 0 gnd and vcc. But it still turns to bootloader. Do you know another important point that effects program's start adress after reset?

[Tesla DeLorean]

Starting *your* bootloader?

Your bootloader needs to validate your application and transfer control to it, if that's what you need.

Where your application is at 0x08020000 you need to facilitate the transfer there.

[G_A.]

Sorry, I did not understand exactly what I should do.

And yes, the system turns to the bootloader I wrote.

[Tesla DeLorean]

Ok, so your bootloader needs to validate/authenticate your application is present, and call it.

Perhaps review some of the IAP / Firmware Upgrade examples if the functionality of a bootloader is unclear.

[G_A.]

Actually my bootloader calls application already. The problem is not be able to stand in user application after reset

[Tesla DeLorean]

Then you'll need to debug that. Perhaps check that a) you've built/linked the code for the correct address, and b) that the vector table is mapped properly via SCB->VTOR, likely in SystemInit()

Other than that you're going to need to step through the transition code and understand where it goes once it gets there. Have effective Hard Fault and Error Handler routines so you can get some useful diagnostics if the processor ends up there.

[G_A.]

HAL_GPIO_TogglePin(GPIOD, GPIO_PIN_12);

HAL_Delay(500);

SystemInit();

pFunction Jump_To_Application = *( (pFunction*) (APPLICATION_START_ADDRESS + 4) );

__set_CONTROL(0);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_15,0);

SysTick->CTRL = 0; //disable SysTick

SCB->VTOR = APPLICATION_START_ADDRESS;

__set_MSP( *( (uint32_t*) APPLICATION_START_ADDRESS ) );

Jump_To_Application();

I am using this part of code for jumping another sector. Also I changed the vector adress in user application code. ( #define VECT_TAB_OFFSET 0xC000

FLASH (rx) : ORIGIN = 0x800c000)

[Tesla DeLorean]

Ok, but going to have to establish what's actually happening.

One could use the debugger, or instrument the code to see what the flow looks like.

I would suggest have the USART working in the bootloader, and then NOT have the application reset/restart the clocks/PLL, and check-point at the app's ResetHandler, main(), etc. so you can establish a point of failure or depth of progress. Instrument Hard Fault Handler's in both bootloader and application, and identify while(1) loops within the code which might hang-up.

[G_A.]

Thanks for your advices. I found the problem. Actually after reset, the turning back to bootloader is a normal situation. But I have should used a flag ikeeping inside information about if there is a new data coming via usart or not. Thus it will pass from bootloader to user app if there is no new data.

Do you know any flag showing if USART dma receive new data?