Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Problem (and fix) for Cortex M3 port

Posted by Artur on May 11, 2008
Hi,

I found a small issue with the port for Cortex M3 (at least for GCC and IAR).
In case when vector table is not located at the begining od FLASH space then initialization of (main) stack will fail.
It is because there is a code like this (file port.c function xPortStartScheduler):

(in version 5.0.0)
vPortStartFirstTask( *((unsigned portLONG *) 0 ) );

(in version 4.7.2)
prvSetMSP( *((unsigned portLONG *) 0 ) );


I found this during debugging my bootloader, so I think that use of any bootloader for application with this port will fail.

For my purposes I defined (in FreeRTOSConfig.h) macro:
#define DEF_APP_ADDRESS0x8002000

and change above lines apropriately to:

vPortStartFirstTask( *((unsigned portLONG *) 0x8002000 ) );
prvSetMSP( *((unsigned portLONG *) 0x8002000 ) );

Regards,
--
Artur Lipowski

RE: Problem (and fix) for Cortex M3 port

Posted by ravaz on May 11, 2008
I had the same problem I solved changing the vPortStartFirstTask like this:

void vPortStartFirstTask(void)
{
__asm volatile(
" ldr r0, =0xE000ED08 \n" /* Load the NVIC_TABLE offset address. */
" ldr r0, [r0] \n" /* Get the vector table offset. */
" ldr r0, [r0] \n" /* Get the stack pointer. */
" msr msp, r0 \n" /* Set the msp back to the start of the stack. */
" svc 0 \n" /* System call to start first task. */
);
}


This way you directly load the stack addres from vector table.

Regards,

Ramon

RE: Problem (and fix) for Cortex M3 port

Posted by Christopher Coley on May 11, 2008
I had the same problme see "Debugging tasks with IAR EWARM" and did a similar fix using __sfb(".intvec"), which is IAR's macro to get the address of the __vector_table section ".intvec". Although getting the NVIC table offset is more portable between compilers.

However this brings up a good question. This is effectively reseting the stack that was created by the compiler for the initialization and setup of FreeRTOS. Although the exit capability "vTaskEndScheduler" of FreeRTOS is currently not implemented in the Cortex-M3 port, reseting the stack would not allow this functionality if we did want it.

Is there a reason the stack gets reset like this at this point?
If not it seems to me that it would be better not to reload the MSP?

RE: Problem (and fix) for Cortex M3 port

Posted by Richard on May 11, 2008
>Is there a reason the stack gets reset like this at this point?

This is just to allow you to reuse/recover some RAM. FreeRTOS.org runs on some pretty tiny CM3 devices, for which it is more relevant. The ports than run onto of DOS are the only ports that really make use of the end scheduler function call, as there you have another OS to return to.

Is there are change request in the SourceForge system already regarding the assumption of the vector table being at zero? I would be grateful if somebody could add one if not, or update the existing one to reference the portable solution.

Thanks for everybody's contribution.

Regards.

RE: Problem (and fix) for Cortex M3 port

Posted by Artur on May 12, 2008
> I would be grateful if somebody could add one if not, or update
> the existing one to reference the portable solution.

Done.
Request ID 1962259.

Regards,
--
Artur Lipowski


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS