No problem. This is the intension of this group.
To make sure that gcc is producing correct entry/exit code you should have look into your object files.
Spurious interrupts occur under some special conditions. If you try to avoid this (e.g. disabling
FIQ/IRQ in PSR instead of VICIntEn) there should be no problem. Have a look to the white papers and
application notes from Philips and ARM concerning this problem.
Sten
gtechnzltd wrote:
> Sten,
>
> Thanks for the link to the #14601 discussion.
>
> So it looks like my functions...
> //exception handling functions
> void IRQ_Routine (void) {while (1) ;}
> void FIQ_Routine (void) {while (1) ;}
> void SWI_Routine (void) {while (1) ;}
> void UNDEF_Routine (void) {while (1) ;}
>
> .... as seen above will operate quite happily so long as I do not
> call any sub routines from them, I think I can live with that!!
>
> Spurious ints..
> To handle the spurious ints I will simply load up the VicDefVectAddr
> reg with a benign function address that will simply allow a spurious
> int to go some where and return back to the main code. The function
> feed into the VivDefVectAddr reg will the defined using the
> attribute_(interrupt) compiler command.
>
> These Arm machine + the Gcc enviroment are quite a bit to get a handle
> on :).
>
> I also found this link which is sort of related to the #14601 on how
> ints are handled, discussion # 9721.
>
> Thanks for you time and efforts in replying.
> Regards
> Grant
> NZ
>
>
>
>
> It looks like I will opt to not call any other function inside my
> "IRQ","SWI" attributed interrupts and leave my vectored interrupts
> with "interrupt" attributed interrupt to do my busy subroutine calls.
>
>
>
>
> --- In lpc2000@yahoogroups.com, Sten <list@...> wrote:
>
>>gtechnzltd wrote:
>>
>>>Hi there,
>>>
>>>Any advice on exception handling. Do you think this is the best
>>>using the GCC tools.
>>>
>>>1: Define the exception handles and functions in main, EG:
>>> //prototype exception handling functions
>>> void IRQ_Routine (void) __attribute__ ((interrupt("IRQ")));
>>> void FIQ_Routine (void) __attribute__ ((interrupt("FIQ")));
>>> void SWI_Routine (void) __attribute__ ((interrupt("SWI")));
>>> void UNDEF_Routine (void) __attribute__ ((interrupt("UNDEF")));
>>>
>>> //exception handling functions
>>> void IRQ_Routine (void) {while (1) ;}
>>> void FIQ_Routine (void) {while (1) ;}
>>> void SWI_Routine (void) {while (1) ;}
>>> void UNDEF_Routine (void) {while (1) ;}
>>>
>>>2: In the start up file define the vectors to the functions in
>
> main EG:
>
>>>Undef_Addr: .word UNDEF_Routine /* defined in main.c */
>>>SWI_Addr: .word SWI_Routine /* defined in main.c */
>>>PAbt_Addr: .word UNDEF_Routine /* defined in main.c */
>>>DAbt_Addr: .word UNDEF_Routine /* defined in main.c */
>>>IRQ_Addr: .word IRQ_Routine /* defined in main.c */
>>>FIQ_Addr: .word FIQ_Routine /* defined in main.c */
>>>
>>>Is this all there is to exception handling?
>>>
>>>Comments welcome.
>>>
>>>Regards
>>>Grant
>>>NZ
>>>
>>>
>>
>>Hello,
>>
>>one week ago we had a discussion about correct code generation using
>
> gcc in conjunction with
>
>>__attribute__((interrupt("IRQ"))). See message #14601.
>>I explored that if you do not call any other functions from an ISR
>
> gcc (4.0.1, 4.1.0) produces
>
>>correct entry/exit code. Otherwise you can get a lot of trouble. In
>
> this thread there are some
>
>>different solutions to avoid it.
>>
>> Sten
>>
>>--
>>/************************************************
>> Do you need a tiny and efficient real time
>> operating system (RTOS) with a preemtive
>> multitasking for LPC2000 or AT91SAM7?
>>
>> http://nanortos.net-attack.de/
>>
>> Or some open-source tools and code for LPC2000?
>>
>> http://www.net-attack.de/
>>
>>************************************************/
>>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
--
/************************************************
Do you need a tiny and efficient real time
operating system (RTOS) with a preemtive
multitasking for LPC2000 or AT91SAM7?
http://nanortos.net-attack.de/
Or some open-source tools and code for LPC2000?
http://www.net-attack.de/
************************************************/Message
Re: [lpc2000] Re: Exception Handling
2006-04-05 by Sten
Attachments
- No local attachments were found for this message.