Custom Bootloader

[embededwarrior]

Current Situation: I have implemented a bootloader that receives a .hex file and writes the application starting from Sector 2. After successfully jumping to the application, the system runs as expected. The Problem: Once the application is running, if I send a new .hex file, it is not accepted by the bootloader unless I perform a hardware reset. Currently, I can only reset the board manually using the reset button. What I Want: I want a software-controlled reset mechanism. When the application is running and a new .hex file is sent (or an update request is detected), the system should trigger a software reset (NVIC_SystemReset()), switch to the bootloader, and allow the new .hex file to be processed automatically—without requiring a hardware reset.

[Ozone]

Obvously because the sequence is:  startup --> bootloader --> application.
Try core_cm<x>.h (in your case core_cm4.h) :
static __INLINE void NVIC_SystemReset(void);

Part of CMSIS, by the way.

[Javier1]

Nice '—'

What was your question?

Your Bootloader can work in any number of fun and weird ways, typically after a Firmware update you could NVIC_SystemReset().

If your Bootloader runs after each reset you might wanna deinitialice remaining Bootloader clock stuff in your compiled UserApplication.hex

  /* USER CODE BEGIN Init */

  HAL_RCC_DeInit();

  /* USER CODE END Init */

[Ozone]

> What was your question?

I am pretty sure the mentioning of "NVIC_SystemReset" was initially part of first post.
Such subsequent changes are not good style, as they disrupt the flow of discussion.
Anyway ...

> The Problem: Once the application is running, if I send a new .hex file, it is not accepted by the bootloader unless I perform a hardware reset.

I think the problem lies within the host application driving the firmware update.
The sequence must be different when target already runs the application.

First step in this case must be a request to the target to go into firmware update mode (bootloader).
This requires not only a reset, but a persistent flag to keep the bootloader in update mode, and not start a valid application. In almost all MCU configurations, an application cannot update itself due to several constraints.
Only when the target is back in BL mode can the host application contact the bootloader, and begin the update process (erase, download, flash).

This is how our ECU bootloaders work.
Firmware update with a running application present is the default use case.

[Javier1]

>> Anyway ... 
I was not asking you, save your eye rolling for someone else.

>>Such subsequent changes are not good style,
Good style, great, very specific, what happened to this community?