Problem (and fix) for Cortex M3 port
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_ADDRESS 0x8002000
and change above lines apropriately to:
vPortStartFirstTask( *((unsigned portLONG *) 0x8002000 ) );
prvSetMSP( *((unsigned portLONG *) 0x8002000 ) );
Regards,
--
Artur Lipowski
Problem (and fix) for Cortex M3 port
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
Problem (and fix) for Cortex M3 port
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?
Problem (and fix) for Cortex M3 port
>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.
Problem (and fix) for Cortex M3 port
> 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