[ECOS] Board is hanging running for long duration

[ECOS] Board is hanging running for long duration

[Neeraja]

Hi,
  
   I am working on at91rm9200 board.Ecos application is running fine but
after running for more than 1 day board is hanging.I could see in
hyperterminal it is coming to the hal_arch_default_isr( )  function with the
interrupt number 1 after the board got hanged.Ethernet interrupt and IRQ0
interupt and two alaram timers  one with one sec and the other with 8 sec
intervals are being used in the application.Could the cause of this can be
spurious interrupt or can any one suggest me what could be the cause for
such behaviour?

Thanks,
Neeraja.

-- 
View this message in context: http://www.nabble.com/Board-is-hanging-running-for-long-duration-tf3844647.html#a10887747
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Board is hanging running for long duration

[Sergei Gavrikov]

Neeraja wrote:
> 
> Hi,
>   
>    I am working on at91rm9200 board.Ecos application is running fine but
> after running for more than 1 day board is hanging.I could see in
> hyperterminal it is coming to the hal_arch_default_isr( )  function with the
> interrupt number 1 after the board got hanged.Ethernet interrupt and IRQ0
> interupt and two alaram timers  one with one sec and the other with 8 sec
> intervals are being used in the application.Could the cause of this can be
> spurious interrupt or can any one suggest me what could be the cause for
> such behaviour?

1. _Seek_ through out the discuss-list and even _grep_ ecos sources
(whole tree) about spurious interrupts report. You will found there the
good bits.

2. Usually, the 'spurious interrupt report' is an issue of bad worked
(or designed) hardware. If there is no man which use same target and cry
about, that means, your hardware fails. Sometimes, some random event
occurs (say, it's a "noise" that can "induct" such event).

3. Run your "a few days in long" test with eCos tracing enabled (to
increase the trace buffers will be a good idea)

cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
cdl_option CYGDBG_USE_TRACING {user_value 1};

4. Well, that occurs. You have a report, you see a chain and you think,
It isn't possible... To ignore such interrupts is a very _bad_ practice.
But, in the some exceptional cases, you can clever (or stupid?) handle
that event without of stop of the application.  Certainly, if there
won't be a whole storm of such events there.

Sergei


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss