I have an instance where I intermittently lose sport data.
I am using an AKM codec that interleaves two channels into sport 0 on
the 21065L. This works perfectly. I get 16 sets of bits, each coming
in and giving me an interrupt every 142us. Runs for hours. Then, for
some odd reason, the interrupt waits for 151us, which is after a 17th
set of bits came through. When I look at the data then, I can clearly
see that my first packet of data is not valid, it is actually what was
sent on the second channel.
Meaning:
Normal operation, codec sends (1)=channel 0, (2)=channel 1,
(3)=channel 0...(15)=channel 0, (16)=channel 1.
16 packets giving a sport interrupt.
I decode (1)=channel 0, (2)=channel 1, (3)=channel 0... properly
Failed operation,
codec sends (1)=channel 0, (2)=channel 1, (3)=channel 0...(15)=channel
0, (16)=channel 1, (17)=channel 0.
observed in a logic analyzer,
I decode (2)=channel 1, (3)=channel 0...(15)=channel 0, (16)=channel
1, (17)=channel 0.
Meaning that the first (1)=channel 0 packet data is lost.
Normally, this means my interrupt handling is slow in re-enabling the
interrupts and dma controllers.
However, this is the first thing I do in the interrupt, is reset the
pointers and dmas and restart the interrupt handlers. All in 15
instructions. Meaning less than 15*5ns. Many ns Long before the first
clocked bit of the first packet ever comes in, so I am definitely fast
enough before the first packet is completed.
I stripped my code down to where the only thing running in the main
loop is... uh, nothing, but jumping to itself.
e.g. main code .... set everything up....
mainloop:
jump mainloop;
so I don't think there is anything going on in the main loop that
causes the error there.
The interrupt routine, I have stripped out all processing, and only do
buffer swapping, and toggling a flag output pin when this erroneous
data order occurs.
I have found it to occur once over night, and I have found it as often
as a few seconds after starting the test.
I have reviewed the timings of the clock and data bits coming into the
sport inputs and they are well within the guidelines for the inputs.
Very aperiodic.
Anyone got any clues?
Anything you know of that MIGHT hold off a sport interrupt?
Thanks in advance.
21065L Sport interrupt held off?
Started by ●March 20, 2006
Reply by ●March 21, 20062006-03-21
On Monday 20 March 2006 20:52, John Henry wrote:
> I have an instance where I intermittently lose sport data.
> I am using an AKM codec that interleaves two channels into sport 0 on
> the 21065L. This works perfectly. I get 16 sets of bits, each coming
> in and giving me an interrupt every 142us. Runs for hours. Then, for
> some odd reason, the interrupt waits for 151us, which is after a 17th
> set of bits came through. When I look at the data then, I can clearly
> see that my first packet of data is not valid, it is actually what was
> sent on the second channel.
> ...
> I have found it to occur once over night, and I have found it as often
> as a few seconds after starting the test.
> I have reviewed the timings of the clock and data bits coming into the
> sport inputs and they are well within the guidelines for the inputs.
> Very aperiodic.
> Anyone got any clues?
> Anything you know of that MIGHT hold off a sport interrupt?
>
> Thanks in advance.
>
There had been issues which had to do with stacking (nesting) interrupts.
Check thoroughly, if this is not the case here!
I had such a conflict some 2 years ago. SPORT data got lost once or twice in
an hour. Reason was that a timer interrupt happened to occur at the same time
as the SPORT interrupt.
The ADI anomaly list should contain a hint, which describes the details.
There are different issues concerning interrupt nesting, and you should handle
data in registers very carefully if such interrupt stacking is possible.
Your problem sounds like of the same sort.
Tracing down such errors can be very annoying.
Another, simplier possibility, which I happened to run into is this:
if your interrupt service routine (ISR) uses almost the whole time between two
interrupts, and if a conditional path exists, which is too long, it might
happen, that your ISR is still processing the interrupt while the next has
already arrived. One interrupt could be lost every time the long path is
taken.
Since I experienced these issues, I do one thing to avoid such conflicts:
The ISR updates some statistical counters, which tell me at least:
- serial number of current ISR
- duration (in clock cycles) of the current ISR
- max duration
- min duration
- avg duration
This helped me to detect the above and lots of other issues, and usually it
helps to keep far enough away from critical borders.
Bernhard
----
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
Ueber das Internet versandte E-Mails koennen leicht unter fremden Namen
erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
ausschliessen.
This E-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this E-mail in
error, please notify the sender immediately and destroy this E-mail. Any
unauthorized copying, disclosure or distribution of the material in this
E-mail is strictly forbidden.
E-mails via Internet can easily be prepared or manipulated by third
persons. For this reason we trust you will understand that, for your own
and our protection, we rule out the legal validity of the foregoing
statements and comments.
> I have an instance where I intermittently lose sport data.
> I am using an AKM codec that interleaves two channels into sport 0 on
> the 21065L. This works perfectly. I get 16 sets of bits, each coming
> in and giving me an interrupt every 142us. Runs for hours. Then, for
> some odd reason, the interrupt waits for 151us, which is after a 17th
> set of bits came through. When I look at the data then, I can clearly
> see that my first packet of data is not valid, it is actually what was
> sent on the second channel.
> ...
> I have found it to occur once over night, and I have found it as often
> as a few seconds after starting the test.
> I have reviewed the timings of the clock and data bits coming into the
> sport inputs and they are well within the guidelines for the inputs.
> Very aperiodic.
> Anyone got any clues?
> Anything you know of that MIGHT hold off a sport interrupt?
>
> Thanks in advance.
>
There had been issues which had to do with stacking (nesting) interrupts.
Check thoroughly, if this is not the case here!
I had such a conflict some 2 years ago. SPORT data got lost once or twice in
an hour. Reason was that a timer interrupt happened to occur at the same time
as the SPORT interrupt.
The ADI anomaly list should contain a hint, which describes the details.
There are different issues concerning interrupt nesting, and you should handle
data in registers very carefully if such interrupt stacking is possible.
Your problem sounds like of the same sort.
Tracing down such errors can be very annoying.
Another, simplier possibility, which I happened to run into is this:
if your interrupt service routine (ISR) uses almost the whole time between two
interrupts, and if a conditional path exists, which is too long, it might
happen, that your ISR is still processing the interrupt while the next has
already arrived. One interrupt could be lost every time the long path is
taken.
Since I experienced these issues, I do one thing to avoid such conflicts:
The ISR updates some statistical counters, which tell me at least:
- serial number of current ISR
- duration (in clock cycles) of the current ISR
- max duration
- min duration
- avg duration
This helped me to detect the above and lots of other issues, and usually it
helps to keep far enough away from critical borders.
Bernhard
----
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
Ueber das Internet versandte E-Mails koennen leicht unter fremden Namen
erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
ausschliessen.
This E-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this E-mail in
error, please notify the sender immediately and destroy this E-mail. Any
unauthorized copying, disclosure or distribution of the material in this
E-mail is strictly forbidden.
E-mails via Internet can easily be prepared or manipulated by third
persons. For this reason we trust you will understand that, for your own
and our protection, we rule out the legal validity of the foregoing
statements and comments.
Reply by ●March 21, 20062006-03-21
I had a problem with interrupts being held off once, it was due to an
external
access that was coincidentally starting right before the interrupt and took a
long time to complete. But if you know your non-interrupt code is doing
nothing but jumping, that probably isn't the case here. Any other interrupts
enabled? Can you trap the condition in software and save the various
interrupt-related registers to see if anything is incorrect?
--- John Henry wrote:
> I have an instance where I intermittently lose sport data.
> I am using an AKM codec that interleaves two channels into sport 0 on
> the 21065L. This works perfectly. I get 16 sets of bits, each coming
> in and giving me an interrupt every 142us. Runs for hours. Then, for
> some odd reason, the interrupt waits for 151us, which is after a 17th
> set of bits came through. When I look at the data then, I can clearly
> see that my first packet of data is not valid, it is actually what was
> sent on the second channel.
> Meaning:
> Normal operation, codec sends (1)=channel 0, (2)=channel 1,
> (3)=channel 0...(15)=channel 0, (16)=channel 1.
> 16 packets giving a sport interrupt.
> I decode (1)=channel 0, (2)=channel 1, (3)=channel 0... properly
> Failed operation,
> codec sends (1)=channel 0, (2)=channel 1, (3)=channel 0...(15)=channel
> 0, (16)=channel 1, (17)=channel 0.
> observed in a logic analyzer,
> I decode (2)=channel 1, (3)=channel 0...(15)=channel 0, (16)=channel
> 1, (17)=channel 0.
> Meaning that the first (1)=channel 0 packet data is lost.
> Normally, this means my interrupt handling is slow in re-enabling the
> interrupts and dma controllers.
> However, this is the first thing I do in the interrupt, is reset the
> pointers and dmas and restart the interrupt handlers. All in 15
> instructions. Meaning less than 15*5ns. Many ns Long before the first
> clocked bit of the first packet ever comes in, so I am definitely fast
> enough before the first packet is completed.
> I stripped my code down to where the only thing running in the main
> loop is... uh, nothing, but jumping to itself.
> e.g. main code > .... set everything up....
> mainloop:
> jump mainloop;
> so I don't think there is anything going on in the main loop that
> causes the error there.
> The interrupt routine, I have stripped out all processing, and only do
> buffer swapping, and toggling a flag output pin when this erroneous
> data order occurs.
> I have found it to occur once over night, and I have found it as often
> as a few seconds after starting the test.
> I have reviewed the timings of the clock and data bits coming into the
> sport inputs and they are well within the guidelines for the inputs.
> Very aperiodic.
> Anyone got any clues?
> Anything you know of that MIGHT hold off a sport interrupt?
>
> Thanks in advance.
__________________________________________________
access that was coincidentally starting right before the interrupt and took a
long time to complete. But if you know your non-interrupt code is doing
nothing but jumping, that probably isn't the case here. Any other interrupts
enabled? Can you trap the condition in software and save the various
interrupt-related registers to see if anything is incorrect?
--- John Henry wrote:
> I have an instance where I intermittently lose sport data.
> I am using an AKM codec that interleaves two channels into sport 0 on
> the 21065L. This works perfectly. I get 16 sets of bits, each coming
> in and giving me an interrupt every 142us. Runs for hours. Then, for
> some odd reason, the interrupt waits for 151us, which is after a 17th
> set of bits came through. When I look at the data then, I can clearly
> see that my first packet of data is not valid, it is actually what was
> sent on the second channel.
> Meaning:
> Normal operation, codec sends (1)=channel 0, (2)=channel 1,
> (3)=channel 0...(15)=channel 0, (16)=channel 1.
> 16 packets giving a sport interrupt.
> I decode (1)=channel 0, (2)=channel 1, (3)=channel 0... properly
> Failed operation,
> codec sends (1)=channel 0, (2)=channel 1, (3)=channel 0...(15)=channel
> 0, (16)=channel 1, (17)=channel 0.
> observed in a logic analyzer,
> I decode (2)=channel 1, (3)=channel 0...(15)=channel 0, (16)=channel
> 1, (17)=channel 0.
> Meaning that the first (1)=channel 0 packet data is lost.
> Normally, this means my interrupt handling is slow in re-enabling the
> interrupts and dma controllers.
> However, this is the first thing I do in the interrupt, is reset the
> pointers and dmas and restart the interrupt handlers. All in 15
> instructions. Meaning less than 15*5ns. Many ns Long before the first
> clocked bit of the first packet ever comes in, so I am definitely fast
> enough before the first packet is completed.
> I stripped my code down to where the only thing running in the main
> loop is... uh, nothing, but jumping to itself.
> e.g. main code > .... set everything up....
> mainloop:
> jump mainloop;
> so I don't think there is anything going on in the main loop that
> causes the error there.
> The interrupt routine, I have stripped out all processing, and only do
> buffer swapping, and toggling a flag output pin when this erroneous
> data order occurs.
> I have found it to occur once over night, and I have found it as often
> as a few seconds after starting the test.
> I have reviewed the timings of the clock and data bits coming into the
> sport inputs and they are well within the guidelines for the inputs.
> Very aperiodic.
> Anyone got any clues?
> Anything you know of that MIGHT hold off a sport interrupt?
>
> Thanks in advance.
__________________________________________________
