21065l sport interrupt, lcntr issue
Started by ●April 19, 2005
I have a strange problem occurring.
I have a 21065L that does DMA through the sports audio in/ audio out,
on interrupt. When buffer gets full, sport interrupts, I swap dma
buffers for outgoing and ingoing, to a second outgoing and ingoing
buffer, so that I can process the full data buffers.
All works fine, except once in a while, failure is not periodic, and
also coincides with a glitch in the clock/data line when writing in
the main loop to an external device. The external device is setup to
be input only on those flag pins.
The problem is, once in a blue moon, I lose the data coming in via the
sport from the codec.
I can probe the line, and it appears to be there, just fine.
Just somehow the dsp decides to stop clocking it, which is then
visible externally on another chip.
Test Scenario I have run is strange.
I was trying to isolate the problem, by setting parts of the code to
generate specific waveforms, and then measuring.
As I went through, I found that I was having the problem occur when
using a lcntr to do a do until lce loop.
I changed it to a counter based (e.g. r13 as a counter), and it worked.
Until I got to the next lcntr, then it failed again.
Note, failure mode is once every 15 or 8 or 20 minutes, not periodic,
but takes a long time, adn the interrupt routine otherwise is handling
the data just perfectly interrupting 6000 times a second.
When I converted the entire interrupt routine to not be lcntr based,
it has not failed in a day.
I have verified that the main routine goes no deeper than 3 loops at
the most. The interrupt routine was only 2 deep, so this was within
the 6 loop count max. Also monitored stky, as it will latch a Loop
Stack Overflow, which it never saw.
I have a work around that works, e.g. make all lcntr loops into a
register counter loop.
I wanted to know if anyone has ever seen anything like this, and if
so, what was your solution? Or anyone else, ideas?
I don't know if the execution of a lcntr actually does anything
electrically different within the DSP, so it may glitch once in a
while, or nto. If it is possible, and some HW is causing a more
current drain, then I need to know so I can make sure I have the right
powers to it also.
Run it with lcntrs, and die within 1 hour.
Run it without, and haven't seen it die yet.
Strange,
Thanks in advance for any help,
John Henry
Sevierville, TN
Reply by ●April 19, 20052005-04-19
Take a look at the documentation on the loop return (LR) flag. This might
be
related to that. Do any of your loops have jumps or calls in them?
Also, sometimes it is a good idea in these types of cases to see what you can
do to make the problem happen MORE often. It is much easier and faster to
trouble-shoot a problem that happens regularly than one that happens only every
20 minutes. Plus, learning what makes it fail often provides clues as to what
will fix it. In that vein, try experimenting with adding in artificial loops
of different lengths (try very short with high repititions, etc.).
--- John Henry <jshenry1963@jshe...> wrote:
> I have a strange problem occurring.
> I have a 21065L that does DMA through the sports audio in/ audio out,
> on interrupt. When buffer gets full, sport interrupts, I swap dma
> buffers for outgoing and ingoing, to a second outgoing and ingoing
> buffer, so that I can process the full data buffers.
> All works fine, except once in a while, failure is not periodic, and
> also coincides with a glitch in the clock/data line when writing in
> the main loop to an external device. The external device is setup to
> be input only on those flag pins.
>
> The problem is, once in a blue moon, I lose the data coming in via the
> sport from the codec.
> I can probe the line, and it appears to be there, just fine.
> Just somehow the dsp decides to stop clocking it, which is then
> visible externally on another chip.
>
> Test Scenario I have run is strange.
> I was trying to isolate the problem, by setting parts of the code to
> generate specific waveforms, and then measuring.
> As I went through, I found that I was having the problem occur when
> using a lcntr to do a do until lce loop.
> I changed it to a counter based (e.g. r13 as a counter), and it worked.
> Until I got to the next lcntr, then it failed again.
> Note, failure mode is once every 15 or 8 or 20 minutes, not periodic,
> but takes a long time, adn the interrupt routine otherwise is handling
> the data just perfectly interrupting 6000 times a second.
> When I converted the entire interrupt routine to not be lcntr based,
> it has not failed in a day.
> I have verified that the main routine goes no deeper than 3 loops at
> the most. The interrupt routine was only 2 deep, so this was within
> the 6 loop count max. Also monitored stky, as it will latch a Loop
> Stack Overflow, which it never saw.
>
> I have a work around that works, e.g. make all lcntr loops into a
> register counter loop.
>
> I wanted to know if anyone has ever seen anything like this, and if
> so, what was your solution? Or anyone else, ideas?
>
> I don't know if the execution of a lcntr actually does anything
> electrically different within the DSP, so it may glitch once in a
> while, or nto. If it is possible, and some HW is causing a more
> current drain, then I need to know so I can make sure I have the right
> powers to it also.
>
> Run it with lcntrs, and die within 1 hour.
> Run it without, and haven't seen it die yet.
>
> Strange,
>
> Thanks in advance for any help,
> John Henry
> Sevierville, TN
>
__________________________________
related to that. Do any of your loops have jumps or calls in them?
Also, sometimes it is a good idea in these types of cases to see what you can
do to make the problem happen MORE often. It is much easier and faster to
trouble-shoot a problem that happens regularly than one that happens only every
20 minutes. Plus, learning what makes it fail often provides clues as to what
will fix it. In that vein, try experimenting with adding in artificial loops
of different lengths (try very short with high repititions, etc.).
--- John Henry <jshenry1963@jshe...> wrote:
> I have a strange problem occurring.
> I have a 21065L that does DMA through the sports audio in/ audio out,
> on interrupt. When buffer gets full, sport interrupts, I swap dma
> buffers for outgoing and ingoing, to a second outgoing and ingoing
> buffer, so that I can process the full data buffers.
> All works fine, except once in a while, failure is not periodic, and
> also coincides with a glitch in the clock/data line when writing in
> the main loop to an external device. The external device is setup to
> be input only on those flag pins.
>
> The problem is, once in a blue moon, I lose the data coming in via the
> sport from the codec.
> I can probe the line, and it appears to be there, just fine.
> Just somehow the dsp decides to stop clocking it, which is then
> visible externally on another chip.
>
> Test Scenario I have run is strange.
> I was trying to isolate the problem, by setting parts of the code to
> generate specific waveforms, and then measuring.
> As I went through, I found that I was having the problem occur when
> using a lcntr to do a do until lce loop.
> I changed it to a counter based (e.g. r13 as a counter), and it worked.
> Until I got to the next lcntr, then it failed again.
> Note, failure mode is once every 15 or 8 or 20 minutes, not periodic,
> but takes a long time, adn the interrupt routine otherwise is handling
> the data just perfectly interrupting 6000 times a second.
> When I converted the entire interrupt routine to not be lcntr based,
> it has not failed in a day.
> I have verified that the main routine goes no deeper than 3 loops at
> the most. The interrupt routine was only 2 deep, so this was within
> the 6 loop count max. Also monitored stky, as it will latch a Loop
> Stack Overflow, which it never saw.
>
> I have a work around that works, e.g. make all lcntr loops into a
> register counter loop.
>
> I wanted to know if anyone has ever seen anything like this, and if
> so, what was your solution? Or anyone else, ideas?
>
> I don't know if the execution of a lcntr actually does anything
> electrically different within the DSP, so it may glitch once in a
> while, or nto. If it is possible, and some HW is causing a more
> current drain, then I need to know so I can make sure I have the right
> powers to it also.
>
> Run it with lcntrs, and die within 1 hour.
> Run it without, and haven't seen it die yet.
>
> Strange,
>
> Thanks in advance for any help,
> John Henry
> Sevierville, TN
>
__________________________________
Reply by ●April 19, 20052005-04-19
On Tue, 19 Apr 2005, Jon Harris wrote:
>
> Take a look at the documentation on the loop return (LR) flag. This might be
> related to that. Do any of your loops have jumps or calls in them?
>
> Also, sometimes it is a good idea in these types of cases to see what you can
> do to make the problem happen MORE often. It is much easier and faster to
> trouble-shoot a problem that happens regularly than one that happens only every
> 20 minutes. Plus, learning what makes it fail often provides clues as to what
> will fix it. In that vein, try experimenting with adding in artificial loops
> of different lengths (try very short with high repititions, etc.).
I agree with Jon, it might be current drain, it might be a confounding
register which has nothing to do with lcntr but appears to be. A work
around is ok to get things going, but if you have time to play, you might
as well see if you can make it happen 6000 times a second. It'll be a lot
easier to find what is really the problem that way.
That's why I don't try to fix things that are intermittant if they aren't
obvious. It's much easier to wait till things fail totally. Kinda rough
when your car breaks down tho :-)
Patience, persistence, truth,
Dr. mike
>
> Take a look at the documentation on the loop return (LR) flag. This might be
> related to that. Do any of your loops have jumps or calls in them?
>
> Also, sometimes it is a good idea in these types of cases to see what you can
> do to make the problem happen MORE often. It is much easier and faster to
> trouble-shoot a problem that happens regularly than one that happens only every
> 20 minutes. Plus, learning what makes it fail often provides clues as to what
> will fix it. In that vein, try experimenting with adding in artificial loops
> of different lengths (try very short with high repititions, etc.).
I agree with Jon, it might be current drain, it might be a confounding
register which has nothing to do with lcntr but appears to be. A work
around is ok to get things going, but if you have time to play, you might
as well see if you can make it happen 6000 times a second. It'll be a lot
easier to find what is really the problem that way.
That's why I don't try to fix things that are intermittant if they aren't
obvious. It's much easier to wait till things fail totally. Kinda rough
when your car breaks down tho :-)
Patience, persistence, truth,
Dr. mike
Reply by ●April 19, 20052005-04-19
Yes, good advice. Also, if you could supply the code that was causing the
problem, we may be able to help you further. Although we have our own custom
kernel and interrupt dispatchers, we run the '65s exactly like this with the
SPORT channels and have never had a problem with LCNTR.
Brett.
> -----Original Message-----
> From: adsp@adsp... [mailto:adsp@adsp...] On
> Behalf Of Jon Harris
> Sent: Tuesday, April 19, 2005 12:46 PM
> To: adsp@adsp...
> Subject: Re: [adsp] 21065l sport interrupt, lcntr issue > Take a look at the documentation on the loop return (LR)
> flag. This might be
> related to that. Do any of your loops have jumps or calls in them?
>
> Also, sometimes it is a good idea in these types of cases to
> see what you can
> do to make the problem happen MORE often. It is much easier
> and faster to
> trouble-shoot a problem that happens regularly than one that
> happens only every
> 20 minutes. Plus, learning what makes it fail often provides
> clues as to what
> will fix it. In that vein, try experimenting with adding in
> artificial loops
> of different lengths (try very short with high repititions, etc.).
>
> --- John Henry <jshenry1963@jshe...> wrote:
> >
> >
> >
> > I have a strange problem occurring.
> > I have a 21065L that does DMA through the sports audio in/
> audio out,
> > on interrupt. When buffer gets full, sport interrupts, I swap dma
> > buffers for outgoing and ingoing, to a second outgoing and ingoing
> > buffer, so that I can process the full data buffers.
> > All works fine, except once in a while, failure is not periodic, and
> > also coincides with a glitch in the clock/data line when writing in
> > the main loop to an external device. The external device is setup to
> > be input only on those flag pins.
> >
> > The problem is, once in a blue moon, I lose the data coming
> in via the
> > sport from the codec.
> > I can probe the line, and it appears to be there, just fine.
> > Just somehow the dsp decides to stop clocking it, which is then
> > visible externally on another chip.
> >
> > Test Scenario I have run is strange.
> > I was trying to isolate the problem, by setting parts of the code to
> > generate specific waveforms, and then measuring.
> > As I went through, I found that I was having the problem occur when
> > using a lcntr to do a do until lce loop.
> > I changed it to a counter based (e.g. r13 as a counter),
> and it worked.
> > Until I got to the next lcntr, then it failed again.
> > Note, failure mode is once every 15 or 8 or 20 minutes, not
> periodic,
> > but takes a long time, adn the interrupt routine otherwise
> is handling
> > the data just perfectly interrupting 6000 times a second.
> > When I converted the entire interrupt routine to not be lcntr based,
> > it has not failed in a day.
> > I have verified that the main routine goes no deeper than 3 loops at
> > the most. The interrupt routine was only 2 deep, so this was within
> > the 6 loop count max. Also monitored stky, as it will latch a Loop
> > Stack Overflow, which it never saw.
> >
> > I have a work around that works, e.g. make all lcntr loops into a
> > register counter loop.
> >
> > I wanted to know if anyone has ever seen anything like this, and if
> > so, what was your solution? Or anyone else, ideas?
> >
> > I don't know if the execution of a lcntr actually does anything
> > electrically different within the DSP, so it may glitch once in a
> > while, or nto. If it is possible, and some HW is causing a more
> > current drain, then I need to know so I can make sure I
> have the right
> > powers to it also.
> >
> > Run it with lcntrs, and die within 1 hour.
> > Run it without, and haven't seen it die yet.
> >
> > Strange,
> >
> > Thanks in advance for any help,
> > John Henry
> > Sevierville, TN
> >
> __________________________________ >
Reply by ●April 20, 20052005-04-20
Hi John,
I remember a problem with using lcntr loops with interrupts - as the processing of an interrupt
is similar to jump instruction execution this may have undesirable effects around the lcntr loop
depending upon when the interrupt occurs.
Looking into my code I found that I had temporarily disabled the virpt interrupt whenever I
used the lcntr loop as a temporary solution - but there was no time (or budget) available to
debug the problem fully.
I hope this helps.
Alex Young
|
"John Henry" <j...@yahoo.com> Sent by:
19/04/05 18:05
|
To: a...@yahoogroups.com cc: (bcc: Alex Young/LEU/PDSL/PHILIPS) Subject: [adsp] 21065l sport interrupt, lcntr issue Classification:
|
I have a 21065L that does DMA through the sports audio in/ audio out,
on interrupt. When buffer gets full, sport interrupts, I swap dma
buffers for outgoing and ingoing, to a second outgoing and ingoing
buffer, so that I can process the full data buffers.
All works fine, except once in a while, failure is not periodic, and
also coincides with a glitch in the clock/data line when writing in
the main loop to an external device. The external device is setup to
be input only on those flag pins.
The problem is, once in a blue moon, I lose the data coming in via the
sport from the codec.
I can probe the line, and it appears to be there, just fine.
Just somehow the dsp decides to stop clocking it, which is then
visible externally on another chip.
Test Scenario I have run is strange.
I was trying to isolate the problem, by setting parts of the code to
generate specific waveforms, and then measuring.
As I went through, I found that I was having the problem occur when
using a lcntr to do a do until lce loop.
I changed it to a counter based (e.g. r13 as a counter), and it worked.
Until I got to the next lcntr, then it failed again.
Note, failure mode is once every 15 or 8 or 20 minutes, not periodic,
but takes a long time, adn the interrupt routine otherwise is handling
the data just perfectly interrupting 6000 times a second.
When I converted the entire interrupt routine to not be lcntr based,
it has not failed in a day.
I have verified that the main routine goes no deeper than 3 loops at
the most. The interrupt routine was only 2 deep, so this was within
the 6 loop count max. Also monitored stky, as it will latch a Loop
Stack Overflow, which it never saw.
I have a work around that works, e.g. make all lcntr loops into a
register counter loop.
I wanted to know if anyone has ever seen anything like this, and if
so, what was your solution? Or anyone else, ideas?
I don't know if the execution of a lcntr actually does anything
electrically different within the DSP, so it may glitch once in a
while, or nto. If it is possible, and some HW is causing a more
current drain, then I need to know so I can make sure I have the right
powers to it also.
Run it with lcntrs, and die within 1 hour.
Run it without, and haven't seen it die yet.
Strange,
Thanks in advance for any help,
John Henry
Sevierville, TN NEW! You can now post a message or access and search the archives of this group on DSPRelated.com:
http://www.dsprelated.com/groups/adsp/1.php
_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group.
_____________________________________
About this discussion group:
Archives: http://www.dsprelated.com/groups/adsp/1.php
To Post: Send an email to a...@yahoogroups.com
Other DSP Related Groups: http://www.dsprelated.com/groups.php
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/adsp/
<*> To unsubscribe from this group, send an email to:
a...@yahoogroups.com
<*>
Reply by ●April 20, 20052005-04-20
--On Wednesday, April 20, 2005 11:05 AM +0200 Alex Young
<alex.young@alex...> wrote:
> I remember a problem with using lcntr loops with interrupts - as the
> processing of an interrupt is similar to jump instruction execution this
> may have undesirable effects around the lcntr loop depending upon when
> the interrupt occurs.
Check the library source code for the interrupt trampolines (the pieces
that save and restore registers before calling your code). I've found
errors in those before and, once reported, ADI promptly updates their copy
and releases an errata release. The symptom is much as you describe, very
intermittent failures when some rarely-used register isn't properly saved
and restored by the trampoline.
<alex.young@alex...> wrote:
> I remember a problem with using lcntr loops with interrupts - as the
> processing of an interrupt is similar to jump instruction execution this
> may have undesirable effects around the lcntr loop depending upon when
> the interrupt occurs.
Check the library source code for the interrupt trampolines (the pieces
that save and restore registers before calling your code). I've found
errors in those before and, once reported, ADI promptly updates their copy
and releases an errata release. The symptom is much as you describe, very
intermittent failures when some rarely-used register isn't properly saved
and restored by the trampoline.
