[ECOS] DSR stops running after heavy interrupts.
Thu Apr 6 09:02:00 GMT 2006
>> 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
>> while. Lowering the serial ISR priority seems to help some, but not
>> eliminate the problem.
>> 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
>> still getting called as well as other ISRs, but the real time clock DSR
>> 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
>> // 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
>> 0x03 but the branch still occurs. The problem may be in how this is
>> 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
>> the "v" register notation). Also not sure why the resulting code refers
>> 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.
I had that experience too, not just with the uart (i'm using a PXA270).
Currently using my FIFO DSRs it works better, but please do more research
on that topic to fix this once and forever.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss