Jump to FreeRTOS application

Partners & Sponsors ST
1

Hi all,

I have developed a bootloader for STM32F412, the bootloader works perfectly with bare-metal apps, however, when I change the user app to be FreeRTOS based, it ceases to work.

I added a blink led in the Hard Fault in both the bootloader and app, but both were not triggered.

Any idea what is going on? Or how to debug it?

void jump_to_application(void) {
    void (*app_reset_handler)(void);
    uint32_t msp_value = *(volatile uint32_t*)(APP_START_ADDRESS + APP_HEADER_SIZE);
    uint32_t reset_handler_address = *(volatile uint32_t*)(APP_START_ADDRESS + APP_HEADER_SIZE + 4);

    __disable_irq();

    HAL_RCC_DeInit();
    HAL_DeInit();

    SysTick->CTRL = 0;
    SysTick->LOAD = 0;
    SysTick->VAL = 0;


    for (uint32_t i = 0; i < 8; i++)
    {
        NVIC->ICER[i] = 0xFFFFFFFF;
        NVIC->ICPR[i] = 0xFFFFFFFF;
    }

    __enable_irq();

    __set_MSP(msp_value);
    __set_PSP(msp_value);
    __set_CONTROL(0);
    app_reset_handler = (void*)reset_handler_address;
    app_reset_handler();
}
2

Hello @Qabudhaim, thanks for your interest in FreeRTOS.

Debugging by settings LED’s can be difficult: you must be sure that the GPIO peripheral has been initialised correctly.

In circuit debugging programs: paid options are: Keil MDK-ARM, IAR Embedded Workbench, CrossWorks for ARM (Rowley Associates), and Atollic TrueSTUDIO.
I am using System Workbench (Eclipse) AC6 (v2.9), which allows me to use a makefile. You can also use STM32CubeIDE.

I wrote bootloaders for STM32F4 and STM32F7, that worked with FreeRTOS.

I changed system_stm32f4xx.c to call my checkBootloader():

 #if defined(DATA_IN_ExtSRAM) || defined(DATA_IN_ExtSDRAM)
     SystemInit_ExtMemCtl(); 
 #endif /* DATA_IN_ExtSRAM || DATA_IN_ExtSDRAM */
          
+    /* Check if bootloader must become active before enabling the PLL. */
+    checkBootloader();
 
     /* Configure the System clock source, PLL Multiplier and Divider factors, 
        AHB/APBx prescalers and Flash settings ----------------------------------*/
     SetSysClock();

The function checkBootloader() might never return, depending on the situation.

It is implemented both in the bootloader (BL) as well as in the app. It may decide to jump from the BL to the app, or vv.

Here is a link to some sources that I developed : hal_bootlib

Don’t try to compile it, you’d loos a lot of time. But when reading it, it might give you some ideas.

3

Can you break the code in the debugger and see what it is doing?

I do not see the code to program VTOR. Did you miss that? Here is a good resource from ARM on writing bootloader: Documentation – Arm Developer.

4

Thanks for the support, I will take a look.

5

Thanks for the support.

I did, everything looks okay from the bootloader, however, I can’t decide if the jump is done or not.

I did after posting the issue. Still no progress, from my understanding, setting the VTOR in the bootloader makes no sense, since the app will overwrite it anyways, correct me if wrong.

On the app side, I changes the VECT_TAB_OFFSET with no progress as well.

My suspect is that the FreeRTOS is not having a fresh start after the jump comparing to the normal Run.

Is there a way to debug the app code after jumping from the bootloader, that would be really helpful. I heard that GDB can assist with this, but never tried it yet. I am using STM32CubeMx for context.

Thanks for your time.

6

You should be able to step over the assembly to find that?

You need to ensure that the application vector table is installed correctly and the usual way to do that is to program VTOR in the bootloader. Why does your application change VTOR? Does your FreeRTOS application work without bootloader?

7

Yes, the the application works without the bootloader.

As far as I know, I have to update the VECT_TAB_OFFSET to match the flash address of my app in system_stm32xxxxx.c in the app directory itself, not the bootloader.

Then when the jump to the vector table occurs, the app will handle everything himself automatically.

I added

SCB->VTOR = 0x08020200

And I check the register before jumping, it is as expected, however, the jump didn’t take place.

8

The biggest issue with BootLoaders can be that they don’t leave with the processor in a reset like state. One big one is leaving interrupts enabled, which can cause faults if they occur before the loaded application is ready for them

9

Actually enabling interrupts doesn’t make sense to me at all.
However, all bootloaders source codes that I found online, have this line:

    __enable_irq();

And jumping without enabling the interrupts never worked. Seems they are necessary when jumping without power cycling.

10

The boot loader may need the interrupts themselves.

It is just a fact that “free-standing” programs are (or should be) designed to be started as if from reset, and will enable the interrupts when they are ready for them.

The problem is that with FreeRTOS, many of the ISRs are going to depend on FreeRTOS primatives having been initialized, and right when you come from the boot loader, that won’t be true. This is especially true for the tick interrupt. Thus FreeRTOS WILL enable the interrupts when it starts the first task.

11

That number seems odd. Most of the parts have some alignment requirements on the values that VTOR can take. Can you share your flash layout?

12

You are right, the bootloader header is 0x200 in size, so the vector table starts at 0x08020200.

I checked the alignment required, and starting at 0x08020200 is totally fine.

13

Just for testing, can you remove this 200 byte header so that the application vector table starts at 0x08020000?

14

Hi all,

Few updates:

I did many experiments, unfortunetly none of them worked.

1- Now the FreeRTOS applications start at 0x08040000
2- I use GDB to debug the application, and it shows that the jump was done, but stuck in the hard fault.

3- These are my registers

(gdb) info registers
r0             0x1                 1
r1             0xe000e100          -536813312
r2             0x8041e04           134487556
r3             0xbe1fc             778748
r4             0xbe1fd             778749
r5             0x0                 0
r6             0x0                 0
r7             0x2003ffe0          537133024
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x80000000          -2147483648
sp             0x2003ffe0          0x2003ffe0
lr             0xfffffff9          -7
pc             0x804075c           0x804075c <HardFault_Handler+4>
xPSR           0x1000003           16777219
fpscr          0x0                 0
msp            0x2003ffe0          0x2003ffe0
--Type <RET> for more, q to quit, c to continue without paging--
psp            0x0                 0x0
primask        0x1                 1
basepri        0x0                 0
faultmask      0x0                 0
control        0x0                 0
(gdb) x/x $pc
0x804075c <HardFault_Handler+4>:	0xb480e7fd
(gdb)

4- The final version of my jump function

void jump_to_application(void) {
    void (*app_reset_handler)(void);
    uint32_t app_msp = *(volatile uint32_t*)(APP_START_ADDRESS + APP_HEADER_SIZE);
    uint32_t reset_handler = *(volatile uint32_t*)(APP_START_ADDRESS + APP_HEADER_SIZE + 4);

    __disable_irq();

    // Stop SysTick
    SysTick->CTRL = 0;
    SysTick->LOAD = 0;
    SysTick->VAL  = 0;

    HAL_RCC_DeInit();
    HAL_DeInit();

    for (uint32_t i = 0; i < 8; i++) {
        NVIC->ICER[i] = 0xFFFFFFFF;
        NVIC->ICPR[i] = 0xFFFFFFFF;
    }

    // Optionally clear DMA/USB specific IRQs
    __HAL_RCC_USB_OTG_FS_CLK_DISABLE();
    HAL_NVIC_DisableIRQ(OTG_FS_IRQn);

    __HAL_RCC_DMA1_FORCE_RESET();
    __HAL_RCC_DMA1_RELEASE_RESET();

    // Set vector table to application
    SCB->VTOR = APP_START_ADDRESS + APP_HEADER_SIZE;
    __DSB();
    __ISB();

    __set_MSP(app_msp);
    __set_CONTROL(0); // Privileged + use MSP
    __DSB();
    __ISB();

    app_reset_handler = (void (*)(void))reset_handler;
    app_reset_handler();
}

5- VTOR value is 0x08040000
6- My linker script is

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 256K
  FLASH    (rx)    : ORIGIN = 0x8040000,   LENGTH = 128K
}
15

Is it possible to share your complete project (both bootloader and the application), so that I can give it a try? I do not have the same hardware but I can give it a try on a different ST Nucleo board.

16

Hi,

Thanks a lot for helping.

Here is the STM32 implementation, note that you may need to have a chip that supports TRNG generation.
https://github.com/Qabudhaim/STM32-Secure-Bootloader

I developed a Python CLI to drive the flashing process:
https://github.com/Qabudhaim/STM32-Bootloader-CLI

Regarding the application, I am working with a FreeRTOS blinky (on PB0) that was generated using CMSIS V2 on CubeMX, not sure if it is worth sharing.

Thanks again for taking the time supporting me.

PS: I am attaching links this way as I am not allowed to post links as a new user.

17

I created a simple bootloader for the NUCLEO-H723ZG board and used your jump_to_application function. I successfully reproduced the HardFault. The root cause turned out to be disabling SysTick too early which was re-enabled by HAL_RCC_DeInit in the same function. This caused the bootloader to jump to the FreeRTOS application with SysTick enabled. As a result, SysTick triggered too early after jumping to the FreeRTOS application, resulting in a HardFault. Below is my working version of the jump_to_application function:

extern ETH_HandleTypeDef heth;
extern UART_HandleTypeDef huart3;

#define APPLICATION_ADDRESS 0x08040000

typedef void ( *ResetHandlerFxn_t )( void );

void jump_to_application( void )
{
    ResetHandlerFxn_t applicationResetHandler;
    uint32_t mspValue = *( volatile uint32_t * ) ( APPLICATION_ADDRESS );
    uint32_t resetHandlerAddress = *( volatile uint32_t * )( APPLICATION_ADDRESS + 4 );

    for( uint32_t i = 0; i < 8; i++ )
    {
        NVIC->ICER[ i ] = 0xFFFFFFFF;
    }

    HAL_RCC_DeInit();
    HAL_ETH_DeInit(&heth);
    HAL_UART_DeInit(&huart3);
    HAL_DeInit();

    for( uint32_t i = 0; i < 8; i++ )
    {
        NVIC->ICPR[ i ] = 0xFFFFFFFF;
    }

    SysTick->CTRL = 0;
    SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk ;

    __set_CONTROL( 0 );

    SCB->VTOR = ( uint32_t ) APPLICATION_ADDRESS;
    __set_MSP( mspValue );
    applicationResetHandler = ( ResetHandlerFxn_t ) resetHandlerAddress;
    applicationResetHandler();
}

Here is the complete project in case you want to take a look: stm32h723.zip (2.4 MB)

18

Hi,

I really appreciate your efforts.

Unfortunately, this solution didn’t work.

I tried the same code, only commenting out the Ethernet and UART as I don’t use them.

Do you have an STM32F4 board laying around?

Thanks again, that is really kind of you.

19

You are doing a lot of things in your bootloader. Can you try creating a simple setup:

  1. Bootloader does nothing but just jumps to the application.
  2. Application just have 1 or 2 tasks periodically blinking LEDs.

For this you do not need any application header. You can take a look at the project I shared for similar setup. This will help us confirm if the problem is in jump_to_application function or not.

20

Hi,

Sorry for the late response.

I removed the headers, and encryption features.

I checked the flash region, and it has the same code as expected.

Still going into the hard fault.

In your app, I noticed it is not setting VTOR, am I right?

I started to suspect that USB peripheral is the issue, since, I am flashing and communicating through the USB CDC.

I can’t think of anything more to debug, any ideas??

Best regards,
Qusai Abudhaim