2025-02-25 11:00 PM - last edited on 2025-02-26 1:38 AM by mƎALLEm
ISSUE: STM32F7 Custom Bootloader - Main Application Not Running After Jump
Details:
Bootloader Memory Definition:
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 1024K
QUADSPI (r) : ORIGIN = 0x90000000, LENGTH = 16M
Application Memory Definition:
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K
FLASH (rx) : ORIGIN = 0x8020000, LENGTH = 896K
QUADSPI (r) : ORIGIN = 0x90000000, LENGTH = 16M
Validation Points:
Bootloader erase & write operations are working correctly.
Custom bootloader successfully writes the application code to both internal and external segments.
A test application that prints text ("I am application") works properly after jumping from the bootloader.
Debug points :
1 > memory utilization by main application
RAM : ORIGIN = 0x20000000, utilization = 320 K
FLASH : ORIGIN = 0x8020000, utilization = 896 K
QUADSPI : ORIGIN = 0x90000000, utilization = 5.18 M
2 > Jump steps after writing application (by custom bootloader)
/*********************************************************************************************
if(gParsePacketData.data[0] == BOOT_STATUS)
{
#define APP_ADDRESS 0x08020000
typedef void (*pFunction)(void);
pFunction JumpToApplication;
uint32_t JumpAddress;
int Temp = 0 ;
vc_prepare_packet_and_send(&huart6,FEEDBACK_COMMAND,FEEDBACK_SUCCESS,&Temp,sizeof(Temp));
// Disable interrupts
__disable_irq();
// Deinitialize peripherals and clocks if needed
// Set vector table to application address
SCB->VTOR = APP_ADDRESS;
// Read the application's stack pointer address
__set_MSP(*(volatile uint32_t*)APP_ADDRESS);
// Get the application's reset vector (entry point)
JumpAddress = *(volatile uint32_t*) (APP_ADDRESS + 4);
JumpToApplication = (pFunction) JumpAddress;
// Enable interrupts (optional, the application should handle it)
__enable_irq();
// Jump to application
JumpToApplication();
/**********************************************************************************/
We would be grateful for any guidance or suggestions you can provide.
Solved! Go to Solution.
2025-02-27 9:13 PM
I've pinpointed an issue in my custom bootloader while writing to QSPI. The main application fails to access the .text section stored in QSPI, likely due to a write error.
Currently, I'm writing 32,768 bytes at a time (received via UART). Additionally, the bootloader takes a significant amount of time to download the firmware.
Could anyone suggest optimizations to speed up the bootloader and ensure reliable QSPI writes? Any insights on handling .text section execution from QSPI would be helpful.
Your solutions and insights have always been incredibly helpful, and I truly appreciate the support. Looking forward to your valuable suggestions!