EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

fiq handler (iar:ERR vs gcc:OK)

Started by Pawel Sikora March 15, 2005
Hi all,

I'm currently testing the new embedded workbench
eval 4.20a. I have a software that perfectly works
with gcc-3.4.x but doesn't work with IAR.
I think the problem is in the IAR specific FIQ
handling. I'm using mulitple IRQs and the
only _one_ FIQ in my embedded system.

The IRQ handler works fine with boths compilers.

typedef void (*visr)();

#ifdef __GNUC__
__attribute__((interrupt("IRQ")))
#else
__irq __arm
#endif
void irq_handler(void)
{
((visr)VICVectAddr)();
VICVectAddr = 0;
}

The FIQ handler works only with GCC.

#ifdef __GNUC__
void __attribute__((interrupt("FIQ"))) fiq_handler()
#else
__fiq __arm void fiq_handler(void)
#endif
{
// some action ...
#ifdef __GNUC__
T1_IR = 0xff;
#else
T1IR = 0xff;
#endif
}

[ cite: philips lpc210x datasheet ]

"The fastest possible FIQ latency is acieved when only
one request is classifed as FIQ, because then the FIQ
service routine can simply start dealing with that
device. But if more than one request is assigned to
the FIQ class, the FIQ service routine can read a
word
from the VIC that identifies which FIQ source(s)
(are)
requesting an interrupt"

[ /cite ]

Where is the problem?

Regards,
Pawel.
__________________________________




Re: fiq handler (iar:ERR vs gcc:OK)

An Engineer's Guide to the LPC2100 Series

Are you sure you are setting up stack in the cstartup file ...???
Standard sample code come with stack definition for IRQ but not for FIQ...
For IAR I can say that their tech. support is very good.
I got following answer from their tech. support which might help you.

First, create the following C function with your ADC code:

#pragma vector=0x1C
__fiq __arm void fiq_handler(void)
{
....
}

Second, add the ..\arm\src\lib\cstartup.s79 into your project
and add:

bic r0,r0,#MODE_BITS ; Clear the mode bits
orr r0,r0,#FIQ_MODE ; Set FIQ mode bits
msr cpsr_c,r0 ; Change the mode
ldr sp,=SFE(FIQ_STACK) & 0xFFFFFFF8 ; End of IRQ_STACK

in between the following code:

mrs r0,cpsr ; Original PSR value
bic r0,r0,#MODE_BITS ; Clear the mode bits
orr r0,r0,#IRQ_MODE ; Set IRQ mode bits
msr cpsr_c,r0 ; Change the mode
ldr sp,=SFE(IRQ_STACK) & 0xFFFFFFF8 ; End of IRQ_STACK

bic r0,r0,#MODE_BITS ; Clear the mode bits
orr r0,r0,#SYS_MODE ; Set System mode bits
msr cpsr_c,r0 ; Change the mode
ldr sp,=SFE(CSTACK) & 0xFFFFFFF8 ; End of CSTACK

to initialize the fiq_sp.

Third, add the following segment definition in the xcl file
(specified in the workbench's menu "Project | Options | Linker |
Config | Linker command file | Override default):

-D_FIQ_STACK_SIZE0
-Z(DATA)FIQ_STACK+_FIQ_STACK_SIZE=RAMSTART-RAMEND

kb shah
----- Original Message -----
From: Pawel Sikora
To:
Sent: Tuesday, March 15, 2005 8:26 AM
Subject: [lpc2000] fiq handler (iar:ERR vs gcc:OK) Hi all,

I'm currently testing the new embedded workbench
eval 4.20a. I have a software that perfectly works
with gcc-3.4.x but doesn't work with IAR.
I think the problem is in the IAR specific FIQ
handling. I'm using mulitple IRQs and the
only _one_ FIQ in my embedded system.

The IRQ handler works fine with boths compilers.

typedef void (*visr)();

#ifdef __GNUC__
__attribute__((interrupt("IRQ")))
#else
__irq __arm
#endif
void irq_handler(void)
{
((visr)VICVectAddr)();
VICVectAddr = 0;
}

The FIQ handler works only with GCC.

#ifdef __GNUC__
void __attribute__((interrupt("FIQ"))) fiq_handler()
#else
__fiq __arm void fiq_handler(void)
#endif
{
// some action ...
#ifdef __GNUC__
T1_IR = 0xff;
#else
T1IR = 0xff;
#endif
}

[ cite: philips lpc210x datasheet ]

"The fastest possible FIQ latency is acieved when only
one request is classifed as FIQ, because then the FIQ
service routine can simply start dealing with that
device. But if more than one request is assigned to
the FIQ class, the FIQ service routine can read a
word
from the VIC that identifies which FIQ source(s)
(are)
requesting an interrupt"

[ /cite ]

Where is the problem?

Regards,
Pawel.
__________________________________

------
Yahoo! Groups Links

a.. To



The 2024 Embedded Online Conference