Custom BootLoader jump to FreeRTOS application

[pfifre]

Posted on May 19, 2014 at 10:23

Hi all,

I've develop a specific bootloader which calling my application.

My application is based on FreeRTOS.

When the application starts after the jump, the firmware crashes in hardfault.

It works fine when I don't use the FreeRTOS scheduler.

I've tested my application (with FreeRTOS enabled) by loading it with the debugger and it works fine.

FreeRTOS starts their tasks by calling SVC.

Then, i've try also to replace the FreeRTOS scheduler starting by a simply __asm volatile (''svc 0'') and I reproduce the same issue.

The application address is 0x0800C000.

Like clive suggested, I have use a system call in my bootloader :

void SVC_Handler(void)

{

pFunction  Jump_To_Application;

uint32_t  JumpAddress;

/* Jump to user application */

JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);

Jump_To_Application = (pFunction) JumpAddress;

__disable_irq();

/* Initialize user application's Stack Pointer */

__set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);

Jump_To_Application();

}

I've checked the VECT_TAB_OFFSET in system_stm32f4xx.c to set it to 0xC000.

Can anybody help me ?

Thanks a lot,

Pascal

#stm32-freertos

[kpavlata9]

Posted on May 20, 2014 at 11:16

Hi,

If I understand your code correctly, you are jumping from your bootloader to your application in context of SVC handler. vPortStartFirstTask function of Freertos calls SVC instruction, but you probably are doing it still inside the SVC handler which results in usage fault for which you probably don't have handler thus you end up in hard fault. check the xPSR's LSB bits upon jump to your application to see whether my hypothesis is right and if so, don't jump in SVC context.

br

karel

[pfifre]

Posted on May 20, 2014 at 11:33

Sorry,

I see that I'm not so clear in my explanation and tests.

I modify and simplify the starting of my application to see if SVCHandler will be call by launching the svc call.

It's just a test. I will re-enable FreeRTOS after.

And, it works fine when I load it and start it with the debugger.

The SVCHandler is called by svc calling.

As you say, I need to Initialize FreeRTOS tasks before the SVC called. I'm agree with you.

The OS can't works with SVC call without initialize the tasks.

But, by this test, I just want to know if the interrupts works fine after the jump.

Normally, when the firmware makes a svc call the SVC Handler process it to extract parameters and switch context.

But, in all cases the SVC Handler is called. I'm right ?

Best regards,

Pascal

[pfifre]

Posted on May 20, 2014 at 11:42

Hi Karel,

No, my BootLoader do not switch in SVC context (that's what I try at the beginning but avoid that now).

Now, my BootLoader simply jump at application address after disable IRQ.

Thanks for your help.

Pascal

[pfifre]

Posted on May 20, 2014 at 11:49

Hi Karel,

The xPSR is set to 0 before jumping to application.

Thanks,

Pascal

[pfifre]

Posted on May 20, 2014 at 16:55

Hi all,

After some debugs I found the problem.

In fact, the problem comes with the portDISABLE_INTERRUPTS macro of FreeRTOS.

This macro calls the ulPortSetInterruptMask function :

__asm volatile \

( \

'' mrs r0, basepri \n'' \

'' mov r1, %0 \n'' \

'' msr basepri, r1 \n'' \

'' bx lr \n'' \

:: ''i'' ( configMAX_SYSCALL_INTERRUPT_PRIORITY ) : ''r0'', ''r1'' \

);

FreeRTOS never call the portENABLE_INTERRUPTS to reset the BASEPRI before launch the SVC call???

Have you an idea?

Best regards,

Pascal

[Tesla DeLorean]

Posted on May 20, 2014 at 17:19

Some other related threads to connect some of the dots. The SVC example was a stab at having an RTOS with USER mode code get into SYSTEM mode for the transition.

https://community.st.com/0D50X00009XkbZhSAJ

 

https://community.st.com/0D50X00009Xkfb1SAB

 

https://community.st.com/0D50X00009Xka1fSAB

 

EDIT: Fixed links within forum after transition to Jive.

[Emiliano Fusari]

Posted on March 16, 2017 at 12:50

I'm facing the same problem on a custom board based on a STM32F767ZI microcontroller.

It seems like the links are dead, is there any other place where I can found a solution to the problem?

Thanks.

[Tesla DeLorean]

Posted on March 16, 2017 at 16:47

A lot of content got damaged in the transition to Jive. Use the SEARCH function to find content relevant to your query.

I've fixed the dead-links above, but there are probably some below those, I don't have time go fix the forum, that's ST's job (you broke, you fix it)

Perhaps rather than posting against 3 year old threads, start a new one, citing the old threads, providing full context of your current issue, and what you've tried from the old ones.

Issues with the F7 parts are likely to be nuanced by things unique to those parts, you'll need to be specific about what 'problem' you are having.

[pfifre]

Posted on May 22, 2014 at 10:14

Thanks Clive for sharing these,

As I understand by reading your links, you suggest me to jump very early in the bootloader code after storing the address value to jump in RAM and Reset the processor?

And then, the application will start very soon without any contaminated initialization.

I think this will be a good idea.

I will try this today.

Best regards,

Pascal

[pfifre]

Posted on May 23, 2014 at 09:20

I've implemented the modification with a MagicRAM and a systemReset.

It works well now !!!

I want to thank you a lot Clive for your great support.

Best regards,

Pascal