This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: problem about interrupt end
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: "jiang jet" <jetjiang at hotmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: 23 Nov 2006 09:43:34 +0000
- Subject: Re: [ECOS] problem about interrupt end
- References: <BAY104-F215DF4D1DB0C0A84555B37DFE20@phx.gbl>
"jiang jet" <jetjiang@hotmail.com> writes:
> thank you for answering my question...
> I trace the interrupt progress, and I found the number is changed when
> the code is going from assembly code to c code(call isr through
> hal_interrupt_handlers)..
> it's the first time for timer to interrupt and then the program breaks
> down..
> do you mean there are some other interrupts or the same intererupts
> happened during this period(from system bootup to the time of the
> first timer interrupt happening)?
It may be the same interrupt happening again. If the interrupt
condition has not been cancelled, it is possible for the interrupt to
be re-delivered as soon as interrupts are re-enabled. If this is
before the stack has been totally unwound, then it will chew its way
down the stack and on into other data.
Note that this is only a suggestion, I have no idea whether this is
what is actually happening in your case.
> and I adjust the stack size ,but it seems it doesn't work :(
It is unlikely that this will have any effect, the stack corruption
will chew up any size of stack very quickly.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss