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

["Joe Porthouse" <jporthouse at toptech dot com>]

Stefan, thanks.  I'm glad to know I'm not the only one experiencing this
problem.

I have made a little more progress.

I still can't explain the issues with the code listed in my first message
with the code checking the return value from the ISR, but I believe it is
somehow working correctly.  I still believe there may be a problem with R4
being checked instead of R0.  I did verify that the memory was the same as
my code window, as well as the flash image.

This is what I did find.

DSR calls are being added to the table... thousands of them... just not
getting serviced.  The all calls that lead to "call_pending_DSRs" seem to
originate from the unlock_inner() routine getting called.  This routine
stops getting called when the problem occurs.  (you can see the logic below)


inline void Cyg_Scheduler::unlock() 
{ 
    // This is an inline wrapper for the real scheduler unlock function in 
    // Cyg_Scheduler::unlock_inner(). 
        
    // Only do anything if the lock is about to go zero, otherwise we simply

    // decrement and return. As with lock() we do not need any special code 
    // to decrement the lock counter. 
     
    CYG_INSTRUMENT_SCHED(UNLOCK,get_sched_lock(),0); 
          
    HAL_REORDER_BARRIER(); 
          
    cyg_ucount32 __lock = get_sched_lock() - 1; 
         
    if( __lock == 0 )
      unlock_inner(0); 
    else
      set_sched_lock(__lock); 
   
    HAL_REORDER_BARRIER(); 
}

Upon examination the __lock value is "6" when unlock() is called at the end
of the ISR, thus unlock_inner never gets called.  If I get the variable
location in the get_sched_lock() back to 1, my DSR calls resume.
Mmmmmmm....

So somehow locks are being done without unlocks.  I am at a loss to figure
out how this is occurring since I do not make lock calls in any of my code.
Could interrupt preemption somehow be occurring?  Does the
hal_disable/enable interrupt calls mess with the lock?

Any good ideas on how to track this down?


Joe Porthouse

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Stefan
Sommerfeld
Sent: Thursday, April 06, 2006 5:01 AM
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] DSR stops running after heavy interrupts.

Hi,

>> 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.

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.

Bye...


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




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