FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2012 Threads] System Tick Interrupt on CortexPosted by Peter Mc Shane on December 8, 2012 I've been using FreeRTOS with the GNU compiler on a Microsemi (Actel) A2F200/A2F500 system which is Cortex M3 based. Whilst looking at the code for the xPortSysTickHandler I was puzzled as to why the function, which is an interrupt handler, was declared as void xPortSysTickHandler( void ). Why is it not __attribute__((__interrupt__)) void xPortSysTickHandler( void )?
Regards, Peter
RE: System Tick Interrupt on CortexPosted by Richard on December 8, 2012 ...because, unlike ARM7/9 cores, a Cortex-M core interrupts is just standard C functions.
Regards.
RE: System Tick Interrupt on CortexPosted by Peter Mc Shane on December 8, 2012 Ah! I missed that fact on my first scan through the exception handling section of the Cortex docs I have.
Thanks for the quick response on a Saturday :)
Regards, Peter
RE: System Tick Interrupt on CortexPosted by Peter Mc Shane on December 13, 2012 Hi Richard,
I've been doing a bit of digging on this and it is not as clear cut as it seems.
There is a potential issue with Cortex systems where the stack is not 8 byte aligned and you call functions with 64 bit parameters. The API specifies that call stacks between modules must be 8 byte aligned but depending on the Cortex model, this is not necessarily guaranteed. The following http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Bgbcjggh.html has details on the issue and how the STKALIGN bit in the CCR register can be used to control this functionality.
With the GNU compiler and a Cortex M3, the __interrupt__ attribute causes the compiler to generate preamble code which guarantees 8 byte alignment but does change the stack frame in a way that is not consistent with the results of setting STKALIGN to 1.
I don't know how much of an issue this is in reality but it might bear further scrutiny.
Regards, Peter
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|