System Tick Interrupt on Cortex

Kernel
1

petermcs wrote on Saturday, December 08, 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

2

rtel wrote on Saturday, December 08, 2012:

…because, unlike ARM7/9 cores, a Cortex-M core interrupts is just standard C functions. 

Regards.

3

petermcs wrote on Saturday, December 08, 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 :slight_smile:

Regards,
Peter

4

petermcs wrote on Thursday, 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