Re: [ECOS] DSR stops running after heavy interrupts.

[Andrew Lunn <andrew at lunn dot ch>]

On Wed, Apr 05, 2006 at 05:09:41PM -0400, Joe Porthouse wrote:
> In a nutshell:
> 	The real time clock DSR stops getting called after several minutes
> of heavy UART ISR traffic.  I have been running into this on and off for a
> while.  Lowering the serial ISR priority seems to help some, but not
> eliminate the problem.
> 
> Background:
> 	Application is on a custom xScale PXA255 board without redboot.
> When problem occurs the Real Time tick clock simply stops updating.  All
> other aspects of the program seem to work correctly.  The real time ISR is
> still getting called as well as other ISRs, but the real time clock DSR is
> no longer called.
> 
> 	In the Vectors.S file I can step through the execution and see what
> is happening.  On return from the ISR the return code is examined to
> determine if a DSR call should be added to the DSL list.  This check is done
> here:
> 
>         // The return value from the handler (in r0) will indicate whether a
> 
>         // DSR is to be posted. Pass this together with a pointer to the
>         // interrupt object we have just used to the interrupt tidy up
> 
>         cmp     v1,#CYGNUM_HAL_INTERRUPT_NONE
>         beq     17f
> 
> 	When the problem occurs the branch (beq) is occurring that skips
> adding the DSR to the list and ends the ISR.  I can see that R0 is correctly
> 0x03 but the branch still occurs.  The problem may be in how this is getting
> compiled.  In my JTAG tool I see the above code as:
> 
> 00008C5C e3740001   CMN       R4,#00000001
> 00008C60 0a000003   BEQ       00008c74 
> 
> 	Obviously there is some assembler substitution going on.  I'm not
> sure why if the value is in r0, why v1 is being checked (not familiar with
> the "v" register notation).  Also not sure why the resulting code refers to
> R4.  R4 has a different value then R1 at this point in the execution.
> 
> 	Any ideas on this?

The fast that this works for a while and then breaks suggests it is
something unusual going on.

When the problem occurs take a look at the actually contents of memory
which contains these instructions. Has it been corrupted? Be careful
with your debugger here. If you just ask it to disassemble the code it
might show you what is in the elf file, not what is in memory. Do a
hex dump and compare the machine code bytes. 

        Andrew

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