From: "Joe Porthouse" <jporthouse@toptech.com>
To: <ecos-discuss@ecos.sourceware.org>
Subject: RE: [ECOS] DSR stops running after heavy interrupts.
Date: Thu, 06 Apr 2006 21:09:00 -0000 [thread overview]
Message-ID: <MDAEMON-F200604061708.AA084954md50000037649@toptech.com> (raw)
In-Reply-To: <002101c65958$a9ad5160$8262fea9@nullnullsix>
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
next prev parent reply other threads:[~2006-04-06 21:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-05 21:09 Joe Porthouse
2006-04-06 6:49 ` Andrew Lunn
2006-04-06 9:02 ` Stefan Sommerfeld
2006-04-06 21:09 ` Joe Porthouse [this message]
2006-04-06 21:19 ` Andrew Lunn
2006-04-08 4:18 ` [ECOS] DSR stops running after heavy interrupts. Bug found? Joe Porthouse
2006-04-09 12:33 ` Andrew Lunn
2006-04-10 4:50 ` [ECOS] " Sergei Organov
2006-04-10 9:36 ` Nick Garnett
2006-04-10 10:44 ` Sergei Organov
2006-04-10 10:59 ` Nick Garnett
2006-04-10 11:15 ` Sergei Organov
2006-04-10 13:20 ` Joe Porthouse
2006-04-10 16:41 ` [ECOS] Re: DSR stops running after heavy interrupts. Spurious Interrupt! Joe Porthouse
2006-04-10 17:20 ` Nick Garnett
2006-04-10 17:44 ` Andrew Lunn
2006-04-10 20:49 ` Joe Porthouse
2006-04-11 4:07 ` Sergei Organov
2006-04-11 8:31 ` Nick Garnett
2006-04-11 4:15 ` Sergei Organov
2006-04-11 8:43 ` Nick Garnett
2006-04-13 7:58 ` [ECOS] How to use the ARM directive DCB in Vectors.S Birahim Larou Fall
2006-04-13 13:28 ` Andrew Lunn
2006-04-13 13:32 ` Birahim Larou Fall
2006-04-21 7:40 ` [ECOS] " Daniel Néri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MDAEMON-F200604061708.AA084954md50000037649@toptech.com \
--to=jporthouse@toptech.com \
--cc=ecos-discuss@ecos.sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).