After testing the talk through code examples, I feel that since it is configured
in TDM mode, as a result of which synchronization between the input DMA channel
and output DMA channel is getting lost, when we halt the program and restart it
without reloading/rebuilding the program.
In order to test for this, I made some changes to configure the code in I2S mode
for ADSP-21489 processor, and I do not observe the any issue with it. Even by
changing the target option to “STOP I/O DMA” , when target is
halted, data transfer is getting resumed properly.
Kindly find the attached code configured for I2S mode, for ADSP-21489
processor.
With this observation, I can only suggest that halting and restarting the code,
configured in TDM mode, might not be a good approach. Just curious to know,
could you please let me know, why you are trying to do so? Maybe we can help in
suggesting you with some alternative for it, if you provide us some more
information regarding what you are actually trying to do in your system.
Thanks all for suggestions and participating in discussion.
Best Regards,
Anshul
________________________________
From: "Frederickson, Ken"
To: Gene Goff ; "a..."
Sent: Monday, February 13, 2012 6:27 PM
Subject: RE: [adsp] Re: SHARC : data receiver (ADC-DAC) or transfer problem
Hello all,
I have seen the same thing on the ADSP-21469, but it is expected. The
audio ISR is depending on an interrupt from only one of the SPORTs, even though
more than one SPORT might be running. That means that the mechanism is
relying on the assumption that all of the SPORTs will be finished collecting
data by the time the one SPORT triggers the interrupt. This is actually a
very tenuous arrangement, as it is highly dependent upon the interrupt, DMA, and
tcb loading priorities of the respective SPORTs. The behavior can also be
affected if your interrupt is based on whether the interrupting SPORT is
transmitting or receiving, because of the relative time of when data is
available to the DMA.
When halting with the debugger, it almost always causes this mechanism to become
out of sync between SPORTs. This happens because the emulator’s
interrupt is the highest priority and the precise timing between SPORTs is
upset. You may be able to avoid this by telling the IDE to stop the SPORT
DMA when stepping (Settings > Target Options > Stop I/O…).
Alternatively, what I do is reinitialize the SPORT interface after halting.
Hope that helps.
Ken
From:a... [mailto:a...] On Behalf Of Gene Goff
Sent: Monday, February 13, 2012 6:51 AM
To: a...
Subject: [adsp] Re: SHARC : data receiver (ADC-DAC) or transfer problem
I have experienced the same problem that Anshul has described - a left/right
signal swapping occurring in the serial SPORT receiver. We have seen this
happen on the ADSP-21262 which uses essentially the same SPORT design as the
ADSP-214xx. I have contacted ADI Tech Support but their reply was simply
"I don't see a problem...whenever you start the SPORT it always receives
the left channel first..." I understand this, but what if we are switching
between different digital audio input sources, or halting. I have gone as
far as disabling and re-enabling the SPORTs after any change in audio routing,
but still once in a while the left/right signals will swap for no known
reason. The Freescale 56K DSP's don't have this problem because
their equivalent serial audio interface has a hardware status register bit which
indicates if the received word occurred in an even or odd numbered time
slot. I would like if ADI could take this problem seriously and
investigate what is causing this problem and enhance their SPORT design to have
a status register tag bit to identify each received word as left or right.
--
Gene Goff
Chief Engineer
Ashly Audio, Inc.
Reply by "Frederickson, Ken"●February 13, 20122012-02-13
Hello all,
I have seen the same thing on the ADSP-21469, but it is expected. The audio ISR
is depending on an interrupt from only one of the SPORTs, even though more than
one SPORT might be running. That means that the mechanism is relying on the
assumption that all of the SPORTs will be finished collecting data by the time
the one SPORT triggers the interrupt. This is actually a very tenuous
arrangement, as it is highly dependent upon the interrupt, DMA, and tcb loading
priorities of the respective SPORTs. The behavior can also be affected if your
interrupt is based on whether the interrupting SPORT is transmitting or
receiving, because of the relative time of when data is available to the DMA.
When halting with the debugger, it almost always causes this mechanism to become
out of sync between SPORTs. This happens because the emulator's interrupt
is the highest priority and the precise timing between SPORTs is upset. You may
be able to avoid this by telling the IDE to stop the SPORT DMA when stepping
(Settings > Target Options > Stop I/O...). Alternatively, what I do is
reinitialize the SPORT interface after halting.
Hope that helps.
Ken
From: a... [mailto:a...] On Behalf Of Gene Goff
Sent: Monday, February 13, 2012 6:51 AM
To: a...
Subject: [adsp] Re: SHARC : data receiver (ADC-DAC) or transfer problem
I have experienced the same problem that Anshul has described - a left/right
signal swapping occurring in the serial SPORT receiver. We have seen this
happen on the ADSP-21262 which uses essentially the same SPORT design as the
ADSP-214xx. I have contacted ADI Tech Support but their reply was simply "I
don't see a problem...whenever you start the SPORT it always receives the
left channel first..." I understand this, but what if we are switching between
different digital audio input sources, or halting. I have gone as far as
disabling and re-enabling the SPORTs after any change in audio routing, but
still once in a while the left/right signals will swap for no known reason. The
Freescale 56K DSP's don't have this problem because their equivalent
serial audio interface has a hardware status register bit which indicates if the
received word occurred in an even or odd numbered time slot. I would like if
ADI could take this problem seriously and investigate what is causing this
problem and enhance their SPORT design to have a status register tag bit to
identify each received word as left or right.
--
Gene Goff
Chief Engineer
Ashly Audio, Inc.
Reply by Gene Goff●February 13, 20122012-02-13
I have experienced the same problem that Anshul has described - a
left/right signal swapping occurring in the serial SPORT receiver. We
have seen this happen on the ADSP-21262 which uses essentially the same
SPORT design as the ADSP-214xx. I have contacted ADI Tech Support but
their reply was simply "I don't see a problem...whenever you start the
SPORT it always receives the left channel first..." I understand this,
but what if we are switching between different digital audio input
sources, or halting. I have gone as far as disabling and re-enabling
the SPORTs after any change in audio routing, but still once in a while
the left/right signals will swap for no known reason. The Freescale 56K
DSP's don't have this problem because their equivalent serial audio
interface has a hardware status register bit which indicates if the
received word occurred in an even or odd numbered time slot. I would
like if ADI could take this problem seriously and investigate what is
causing this problem and enhance their SPORT design to have a status
register tag bit to identify each received word as left or right.
--
Gene Goff
Chief Engineer
Ashly Audio, Inc.
Reply by Mike Rosing●February 10, 20122012-02-10
If your program is using dma, it may be that your "problem" is that the
dma engine continues to run. If there are timer interrupts you can
suspend them by going into Settings->Target Options->Mask interrupts
during step. You are dealing with a dynamic system, pausing things in the
middle tends to break everything. If it starts up and gets past an
initial glitch and then continues ok, then I don't think you have a real
problem with the data transfer.
If all your data is screwed up, then single stepping with interrupts
masked can help you find out what is getting messed up.
Patience, persistence, truth,
Dr. mike
On Fri, 10 Feb 2012, Anshul wrote:
> Hi all,
>
> I am developing a project based on Talkthru example for ADSP-214xx (21489
AD1939 C Block-Based Talkthru 48 or 96 kHz). While debugging the project I
noticed strange behavior with Codecs Input/Output. The problem occurs if you
HALT a running program on DSP and than restart it without loading / reloading /
rebuilding the project. While looking for the problem, I also tested the default
Talkthru example and found that the problem may be because of interrupt
scheduler ( or something else ? ) in Talkthru example.
>
> The strange behavior which I noticed is as follows:
>
> - One of the Receiver channel ( fBlockA.Rx_L2 or fBlockA.Rx_R2) may have
garbage value even though the input signal is same for both channels
>
> - Cross transfer between Receiver buffers and Transmitter buffers
>
> fBlockA.Rx_L2 ------------------------> fBlockA.Tx_R3
>
> fBlockA.Rx_R2 ------------------------> fBlockA.Tx_L3
>
> fBlockA.Rx_L2 ------------------------> fBlockA.Tx_L4
>
> fBlockA.Rx_R2 ------------------------> fBlockA.Tx_R4
>
> or
>
> fBlockA.Rx_L2 ------------------------> fBlockA.Tx_L3
>
> fBlockA.Rx_R2 ------------------------> fBlockA.Tx_R3
>
> fBlockA.Rx_L2 ------------------------> fBlockA.Tx_R4
>
> fBlockA.Rx_R2 ------------------------>fBlockA.Tx_L4
>
> - One of the receiver channel (e.g. fBolockA.Rx_R2) may have approximately
double the value of another receiver channel (e.g. fBlockA.Rx_L2)
>
> I am using Visual DSP++ 5.0 update 10 on windows xp ( target connection
through HPUSB-ICE )
>
> Thank you very much.
>
> ARS
>
Reply by Anshul●February 10, 20122012-02-10
Hi all,
I am developing a project based on Talkthru example for ADSP-214xx (21489 AD1939
C Block-Based Talkthru 48 or 96 kHz). While debugging the project I noticed
strange behavior with Codecs Input/Output. The problem occurs if you HALT a
running program on DSP and than restart it without loading / reloading /
rebuilding the project. While looking for the problem, I also tested the default
Talkthru example and found that the problem may be because of interrupt
scheduler ( or something else ? ) in Talkthru example.
The strange behavior which I noticed is as follows:
- One of the Receiver channel ( fBlockA.Rx_L2 or fBlockA.Rx_R2) may have garbage
value even though the input signal is same for both channels
- Cross transfer between Receiver buffers and Transmitter buffers