Quality RTOS & Embedded Software

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


Loading

Default vPortSVCHandler() issue

Posted by ssun on August 16, 2012
The default SVC handler: vPortSVCHandler is making an exception due to lr error on the CM3/4 with armgcc.

The implementation of the vPortSVCHandler() is simplely adding a function in the main.c:
void SVC_Handler(void)
{
vPortSVCHandler();
}

When entering the SVC mode, beginning address of SVC_Handler(), the lr value is correct: 0xfffffff9. But when stepping in, after entering vPortSVCHandler, the lr will changed to the SVC_Handler() ! It is supposed to 0xffffff9 as the default SVC handler code:
" orr r14, #0xd \n"
" bx r14 \n"

So is this a compiler issue or code issue? If we add a "mov r14, #0xfffffff9 \n" before the "orr r14, #0xd \n", the code will working. But the same code works on the IAR EWARM and codesourcery.

The armgcc version is arm-none-eabi-gcc.exe (crosstool-NG 1.13.1 - Atmel build: 13) 4.6.1

RE: Default vPortSVCHandler() issue

Posted by Richard on August 16, 2012
“The default SVC handler: vPortSVCHandler is making an exception due to lr error on the CM3/4 with armgcc.

The implementation of the vPortSVCHandler() is simplely adding a function in the main.c:
void SVC_Handler(void)
{
vPortSVCHandler();
}”


I have no idea where you got that code from, or why you think it is the default implementation. There are lots of official examples that run on the Cortex-M cores, and none do it like that.

Where did this code come from?

“So is this a compiler issue or code issue?”


Neither. Please either install the vectors directly in the Cortex-M vector table, or map the FreeRTOS handler functions to their CMSIS names. For example, see
http://www.freertos.org/FreeRTOS_Support_Forum_Archive/January_2012/freertos_LPC1768_FreeRTOS_4964917.html

Regards.

RE: Default vPortSVCHandler() issue

Posted by ssun on August 16, 2012
Thanks, Richard,

The code is from unzipped FreeRTOSV7.2.0.exe, \FreeRTOSV7.2.0\FreeRTOS\Source\portable\GCC\ARM_CM3\port.c, line 145. That's why i call it as a default.

The vector table should be right as the same code is working on the IAR EWARM 6.2 and codesourcery GCC:arm-none-eabi-gcc (Sourcery G++ Lite 2011.03-42) 4.5.2.
But it is not working only on the arm-none-eabi-gcc.exe (crosstool-NG 1.13.1 - Atmel build: 13) 4.6.1.

It seemslike a compiler issue as 2 toolchain works and only 1 fails. But if we added the "mov r14, #0xfffffff9 \n" to update the lr in the SVC handler, the code is working.

The problem is when the code running from SVC_Handler() to vPortSVCHandler(), the lr is changed. It can and should be changed as it is a APCS call. If we set a breakpoint at vPortSVCHandler(), the lr value is the address of SVC_Handler().

But on the IAR, on the other hand, this toolchain has optimize the code. If we set a breakpoint on the beginning of vPortSVCHandler(), the lr value is 0xfffffff9 which proved the optimization.

So that's why i'm a bit confused. Is it a compile issue or a code issue. If a compile issue, how can we reslove it?

RE: Default vPortSVCHandler() issue

Posted by Richard on August 16, 2012
“The code is from unzipped FreeRTOSV7.2.0.exe, \FreeRTOSV7.2.0\FreeRTOS\Source\portable\GCC\ARM_CM3\port.c, line 145. That's why i call it as a default.”


Are you saying that when you look at line 145 of that file you are seeing the code:

void SVC_Handler(void)
{
vPortSVCHandler();
}



...because when I unzip the same file and look at line 145, I see the correct code (reformatted to fit the screen):

void vPortSVCHandler( void )
{
__asm volatile (
" ldr r3, pxCurrentTCBConst2 \n"
" ldr r1, [r3] \n"
" ldr r0, [r1] \n"
" ldmia r0!, {r4-r11} \n"
" msr psp, r0 \n"
" mov r0, #0 \n"
" msr basepri, r0 \n"
" orr r14, #0xd \n"
" bx r14 \n"
" \n"
" .align 2 \n"
"pxCurrentTCBConst2: .word pxCurrentTCB \n"
);
}



And looking in SVN, I see the same thing:
http://freertos.svn.sourceforge.net/viewvc/freertos/tags/V7.2.0/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c?revision=1773&view=markup

So I am still confused as to what you are looking at, and/or where the code you have came from?

Regards.

RE: Default vPortSVCHandler() issue

Posted by ssun on August 16, 2012
Sorry, the void SVC_Handler(void) is a newly added function and this is the standard exception handler for SVC. The default code meant is the later one you pointed out.

The vector table is set to the right address.

typedef struct _DeviceVectors
{
/* Stack pointer */
void* pvStack;

/* Cortex-M handlers */
void* pfnReset_Handler;
void* pfnNMI_Handler;
void* pfnHardFault_Handler;
void* pfnMemManage_Handler;
void* pfnBusFault_Handler;
void* pfnUsageFault_Handler;
void* pfnReserved1_Handler;
void* pfnReserved2_Handler;
void* pfnReserved3_Handler;
void* pfnReserved4_Handler;
void* pfnSVC_Handler;
void* pfnDebugMon_Handler;
void* pfnReserved5_Handler;
void* pfnPendSV_Handler;
void* pfnSysTick_Handler;
...
}

RE: Default vPortSVCHandler() issue

Posted by Richard on August 16, 2012
So you are reporting a problem in your own code ;o) If you revert your changes you should find it works fine.

Regards.


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


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

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

Xilinx Microblaze and Zynq partner