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
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.
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?
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):
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.