cancel
Showing results for 
Search instead for 
Did you mean: 

CUSTOM BOOTLOADER

Vishwajeet
Associate

 

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.

10 REPLIES 10

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!