Jump from UART internal bootloader to Application code issue

[Rushik_Kanabar]

Hi Everyone,

I am using stm32u575 microcontroller. I am facing issue of stuck the application code in Hardfault handler when jump from internal UART bootloader to the Newly written application code.

Lets explain you the full process. I have a application code of FreeRTOS CMSIS 2 is running. Then, I give a command for jump to the Internal UART bootloader. The application code jump function triggers. The jump function has includes Disable all interrupts along with clear pending interrupts, deinitialize all peripherals, Disable all peripheral clocks, disable systick timer and Freertos Time base timer 6, function pointer for jump to Internal UART bootloader address etc. After this jump function executes, the Stack pointer goes to internal UART bootloader. The UART bootloader erases the application code and will write new application code that captures packets via UART communication. After the whole binary file of FreeRTOS new application process has been completed, I am triggers GO command (0x21) along with new application base address that is 0x08000000. The GO command will add 0x04 to the address and jump to the newly written application code. After jump to the new FreeRTOS application code, the code directly goes to the Hardfault handler.

When I press the RESET button of STM32, the newly updated binary file is running properly. But it requires my manual intervention that I don't want.

Can anybody know what is the cause of this problem and how can I Run the newly flashed binary after DFU update?

If you have any queries, please let me know.

Thanks,

Rushik Kanabar

[Tesla DeLorean]

Root cause the Hard Fault

or watch dog reset out of the HardFault_Handler?

[Rushik_Kanabar]

Thanks Tesla Deloren for reply.

Sorry but Hardfault is the problem not root cause, I want to know root cause of why code go to Hardfault Handler.

I can't use watchdog reset because If I use it, I want to know exect time of whole DFU transfer. But that varies according to code and if it triggers in between the DFU transfer process, my new application code will be corrupted. Also application note strictly noted that if watchdog is defined then set it max value to very high that doesn't triggers before enter to UART bootloader. So I can't do that.

Anybody have other solutions?

[Tesla DeLorean]

Sorry, so what IS causing the Hard Fault, show output from useful instrumentation..

Call code that does a NVIC_SystemReset or WDG more directly then. Or something that spins on USB detach state and THEN reset.

How can you call GO if the process hasn't completed?

The time the DFU or UART loaders take should be irrelevant, you're calling GO to initiate the start / restart

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

[Rushik_Kanabar]

The Hard fault Handler is the function that calls when we try to access invalid memory address or invalid code.

In my case, I can see this Hardfault Handler function using stm32cubeprogrammer and stm32 cube ide as well.

The stm32cube programmer has provided feature to detect the where the code is using hot plug mode and I can see the address of the last intruction by reading PC - Program Counter and LR - Link Registor values that have address of Hardfault handler function. I can see this address while running stm32cube ide in debug mode after this whole process has completed. I can share you screenshot by tomorrow.

Calling NVIC Reset is the good suggestion, but I have tried it also the FreeRTOS application code not reaching to the NVIC Reset function. Watchdog Reset can work but that is the trick and I want to go with systematic approch that's why I could not want to use that.

I am calling GO - 0x21 along with address after the the whole firmware successfuly transfered and its CRC perfwctly matches that is handle by Internal UART boot loader design by STM32. They have explained entire process in the "AN3155 USART protocol used in the STM32 bootloader" document. Link 

I do receive Positive acknowledgement after give GO command before jump to the application address that is 0x08000000.

Thanks for your suggestion Tesla Delorean.

I request STM32 team, Please tell me the systematic approch to solve this issue.

[Tesla DeLorean]

Create a Vector Table that points to a Reset_Handler that just does a HW reset. Could be in RAM, or some faux one in FLASH, etc.

[Rushik_Kanabar]

Are you talking about something like edit VTOR register? Can you give me exact process for doing that in newly updated binary so it can automatically triggers NVIC Reset?

[Tesla DeLorean]

The GO command wants you to point to a SP/PC pair, point it at a structure that achieves that.

Say 0x20002000 and the address of the NVIC_SystemReset() function..

[Rushik_Kanabar]

Indeed, the GO command can point me at any valid address from Flash / RAM and I have tried to put NVIC Reset function along with gpio initialization and put it pin high as an function pointer named as "void ResetFunc(void);" in last 2KB sector of the Flash. I had also updated the linker script of Flash. But that updated function pointer was not triggered that I had checked gpio pin state with logic analyser also.

But If you are talking about to add NVIC reset function in RAM address, I don't know how to add that function in RAM address and call using GO command. Could you please elaborate more about it?

[Tesla DeLorean]

Depending on the System Loader in question you can write content to memory, and transfer control to it.

Moving stuff to RAM and running it is a method used for "staged loaders"

Not tried the U5

Perhaps work with your supervisor or senior staff on approaches to this. If the Hard Fault Handler is firing and blocking you, perhaps focus on debugging that, or utilizing the fact it's executing that code, and you know where it is. Add monitor code so you can interact with the system in that state to inspect what's happening, absent a debugger.