Stm32F437 custom bootloader

PgT72 · ‎2024-09-19

Hi everybody

I'm developing a simple bootloader which run an application loaded in flash memory at the address 0x80200000.

The application alone works correctly but when I use the boot the app doesn't run.

This is the code of my boootloader

#define ACTIVE_FW_BASE_ADDRESS  0x08020000

static void SBL_BootFW()
{
    void (*app_reset_handler)(void); //Function pointer to hold the address of the reset handler of the Firmware
    uint32_t msp_value = *(volatile uint32_t *)ACTIVE_FW_BASE_ADDRESS; //Firmware starting address

    /* STEP 1: Update Interrupt Vector Table */
    SCB->VTOR = (ACTIVE_FW_BASE_ADDRESS);

    /* STEP 2: Configure the MSP by reading the value from the base address of the sector 2 */
    __set_MSP(msp_value);

    /* STEP 3: Fetch the reset handler address of the Firmware from its starting address + 4 */
    uint32_t resethandler_address = *(volatile uint32_t *)(ACTIVE_FW_BASE_ADDRESS + 4);
    app_reset_handler = (void*)resethandler_address;

    /* STEP 4: Jump to the reset handler of the Firmware */
    app_reset_handler();
}

And the FALSH:ld of the application:

/* Memories definition */
MEMORY
{
  CCMRAM    (xrw)    : ORIGIN = 0x10000000,   LENGTH = 64K
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 192K
  FLASH    (rx)    : ORIGIN = 0x8020000,   LENGTH = 2048K - 128k
}

Someone have some suggestions?

Thanks in advance

PgT72 · ‎2024-09-26

I found the problem
My application implements some functionality with RNG and about that the PLLQ clock
was enabled with a divisor by 6.
In the code of my bootloader the PLLQ clock divisor was by 4 , this differrence determines the inability af my application to run when was launched by the boot.
In the bootloade I set the divisor by 6 and now all works fine

Hi Tesla, thanks for your help

View solution in original post

Tesla DeLorean · ‎2024-09-19

Unfortunately "Doesn't Work" is a very unhelpful diagnostic observation.

Instrument Code so as not to fumble blindly

Check the SP and PC are valid, ie aligned and point to RAM, and PC address is ODD and in FLASH

Check not 0xFFFFFFFF

Use a DEBUGGER, step the transition, step into Reset_Handler on App side, how far does it get?

Check SystemInit() on the App side sets SCB->VTOR of your vector table, perhaps use symbols rather than #defines

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

PgT72 · ‎2024-09-23

Hi Tesla

Thanks a lot for your reply , I'm apologise for the delay but i'm trying to fix the issue , unfortunately whithout results.
Anyway , I'm developing a freertos app with STM32F437II microcontroller , at moment the application works fine itself but don't work if I try to launch this with a specific bootloader.

First of all I checked all the references and I don't see anything strange ,
in particular the memory definition of my application is:

CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 192K
FLASH (rx) : ORIGIN = 0x8020000, LENGTH = 2048K - 128k

If I make the dump of the flash at the address 0x08200000 I see that the application is correctly loaded at the specific address and the first 4 words of the app assume the value below:

ADDRESS 0 4 8 C
0x08200000 20030000 080220DD 08020AE9 08020AF1

As you can see the stack pointer is in top of the Ram at the address 0x20030000 and the reset handler is located at the address 0x080220DD.

Stack 0x20030000
reset handler 0x080220DD

When i run the boot and i stop it before the jump , I can observe that the registers assumes these values:

msp_value 0x20030000
SCB->VTOR 0x08020000
app_reset_handler 0x080220DD
pc 0x800050c
xpsr 0x1000000 (thumb)

Inside .list file of the app I can see that the value of reset_Handler is correct

080220dc <Reset_Handler>:

Although the registry values semms correct the application donì't run,
but if i use the ST-Link debugger with the vector table relocated at the offset 0x00020000
the application start and all works fine

PgT72 · ‎2024-09-23