Skip to main content
Visitor II
September 19, 2024
Solved

Stm32F437 custom bootloader

  • September 19, 2024
  • 2 replies
  • 1345 views
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
    This topic has been closed for replies.
    Best answer by PgT72


    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

    2 replies

    Graduate II
    September 19, 2024

    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

    PgT72Author
    Visitor II
    September 23, 2024

    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

    PgT72AuthorAnswer
    Visitor II
    September 26, 2024


    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

    PgT72Author
    Visitor II
    September 23, 2024

    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