Hi Guys
I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
I just get a distorted sound on the analogue output that is loosely based on the
Analogue input signal.
I can get a perfectly clean signal out if I change the OSC SEL links to EXT
instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to 96kHz
instead of 48kHz).
I have not yet done the SDI version 2.5 update the the firmware.
Does anyone know if this update is needed to run the Audio Pass Through Demo or
if it is only required when I come to using the SDI software it's self?
Thanks for your help
Pete Johnston
Nubbie DSPAUDIOEVM 56720 Pass Through distortion
Started by ●August 5, 2009
Reply by ●August 7, 20092009-08-07
Hi Pete,
please jumper AUX3 and AUX5 on JP11 for the analog input. AUX1 and AUX2 are to be used additionally to select digital inputs RX1 to RX4. See Table 2.5 on page 5 in the DSPAUDIOMUG.pdf user manual. If you leave AUX5 unpopulated, you have to access the DSP by the SDI software.
The dual core DSPs (DSP567xx) require an update for older boards as mentioned in DSP56720BUG.pdf. If you simply run the passthrough code from the EEPROM or debug the DSP via the OnCE or parallel interface this update is not required. I cannot understand why changing the connection from INT/INT to ext makes any difference, INT is the internal oscillator using a crystal, EXT is an internal oscillator with the same clock frequency (both 24.5776MHz).
Could you please provide a list with _all_ jumpers populated on both the motherboard and daughterboard? A photopraph would help as well.
Could you please forward the exact ordering code for the DSPX72YDBZE (this is the silk print on the board gthat can be populated with different DSPs), The daughterboard can be populated with DSP56720, DSP56721, DSP56724 or DSP56725. The version name can be found on the package where the daughterboard was shipped in, if you lost this take a closer look to the laser engravement on the DSP chip itself. The reason why I ask for this are the different jumper settings for the daughterboards to get the passthrough code running.
Best regards
Christian
Hi Guys
>
>I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>
>I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>
>I just get a distorted sound on the analogue output that is loosely based on the Analogue input signal.
>
>I can get a perfectly clean signal out if I change the OSC SEL links to EXT instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to 96kHz instead of 48kHz).
>
>I have not yet done the SDI version 2.5 update the the firmware.
>
>Does anyone know if this update is needed to run the Audio Pass Through Demo or if it is only required when I come to using the SDI software it's self?
>
>Thanks for your help
>
>Pete Johnston
please jumper AUX3 and AUX5 on JP11 for the analog input. AUX1 and AUX2 are to be used additionally to select digital inputs RX1 to RX4. See Table 2.5 on page 5 in the DSPAUDIOMUG.pdf user manual. If you leave AUX5 unpopulated, you have to access the DSP by the SDI software.
The dual core DSPs (DSP567xx) require an update for older boards as mentioned in DSP56720BUG.pdf. If you simply run the passthrough code from the EEPROM or debug the DSP via the OnCE or parallel interface this update is not required. I cannot understand why changing the connection from INT/INT to ext makes any difference, INT is the internal oscillator using a crystal, EXT is an internal oscillator with the same clock frequency (both 24.5776MHz).
Could you please provide a list with _all_ jumpers populated on both the motherboard and daughterboard? A photopraph would help as well.
Could you please forward the exact ordering code for the DSPX72YDBZE (this is the silk print on the board gthat can be populated with different DSPs), The daughterboard can be populated with DSP56720, DSP56721, DSP56724 or DSP56725. The version name can be found on the package where the daughterboard was shipped in, if you lost this take a closer look to the laser engravement on the DSP chip itself. The reason why I ask for this are the different jumper settings for the daughterboards to get the passthrough code running.
Best regards
Christian
Hi Guys
>
>I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>
>I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>
>I just get a distorted sound on the analogue output that is loosely based on the Analogue input signal.
>
>I can get a perfectly clean signal out if I change the OSC SEL links to EXT instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to 96kHz instead of 48kHz).
>
>I have not yet done the SDI version 2.5 update the the firmware.
>
>Does anyone know if this update is needed to run the Audio Pass Through Demo or if it is only required when I come to using the SDI software it's self?
>
>Thanks for your help
>
>Pete Johnston
Reply by ●August 7, 20092009-08-07
Hi Pete,
The SDI debugger software is designed for use with the Software Architecture
contained within the ROM of the DSP. The SDI debugger is not designed for
use as a stand-alone, general purpose debugger. For passthru case, it's a
stand-alone case, not required to use SDI to update firmware of EVM. You can
also check your mother board version number. Rev D? RevD actually has the
latest firmware.
I'm not sure the actualy passthru code how to handle clock. I guess digital
or analog input rx and tx clock are all set to slave mode and synced
from AK4114 on mother board. There is a 24.576MHz XTAL on the mother board.
It's the XTAL source of above AK4114. It's also connected to EXT of daughter
board. If we set daughter's EXT as OSC source, that means DSP also drived by
this 24.576 XTAL. But if select INT INT as OSC source, it should also work
properly. It's strange, need more investigation.
--
Best Regards.
Johnny Chen
2009/8/3, p...@blueyonder.co.uk :
>
> Hi Guys
>
> I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>
> I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>
> I just get a distorted sound on the analogue output that is loosely based
> on the Analogue input signal.
>
> I can get a perfectly clean signal out if I change the OSC SEL links to EXT
> instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to
> 96kHz instead of 48kHz).
>
> I have not yet done the SDI version 2.5 update the the firmware.
>
> Does anyone know if this update is needed to run the Audio Pass Through
> Demo or if it is only required when I come to using the SDI software it's
> self?
>
> Thanks for your help
>
> Pete Johnston
The SDI debugger software is designed for use with the Software Architecture
contained within the ROM of the DSP. The SDI debugger is not designed for
use as a stand-alone, general purpose debugger. For passthru case, it's a
stand-alone case, not required to use SDI to update firmware of EVM. You can
also check your mother board version number. Rev D? RevD actually has the
latest firmware.
I'm not sure the actualy passthru code how to handle clock. I guess digital
or analog input rx and tx clock are all set to slave mode and synced
from AK4114 on mother board. There is a 24.576MHz XTAL on the mother board.
It's the XTAL source of above AK4114. It's also connected to EXT of daughter
board. If we set daughter's EXT as OSC source, that means DSP also drived by
this 24.576 XTAL. But if select INT INT as OSC source, it should also work
properly. It's strange, need more investigation.
--
Best Regards.
Johnny Chen
2009/8/3, p...@blueyonder.co.uk :
>
> Hi Guys
>
> I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>
> I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>
> I just get a distorted sound on the analogue output that is loosely based
> on the Analogue input signal.
>
> I can get a perfectly clean signal out if I change the OSC SEL links to EXT
> instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to
> 96kHz instead of 48kHz).
>
> I have not yet done the SDI version 2.5 update the the firmware.
>
> Does anyone know if this update is needed to run the Audio Pass Through
> Demo or if it is only required when I come to using the SDI software it's
> self?
>
> Thanks for your help
>
> Pete Johnston
Reply by ●August 9, 20092009-08-09
Hi Pete and Johnny,
the daughterboard gets an identical clock frequency both with the internal oscillator plus chrystal or external oscilator chip. The external configuration should work without any problem. If not so, please use an oscilloscope probe to check the clock signal.
Pete uses a rev. D motherboard anyway so there is no need for an update. We discussed the jumper settings for both the motherboard and daughterboard already. The strange thing is that he has to jumper AUX1 for the analog input as well what is not listed in thedocumentation as a valid mode setting.
The passthru clock uses a signal derived from the 24.576MHz master clock for the AD and DA converters and a clock derived from the Receiver PLL if you use a digital input. The audio clock doesn't need to by in sync to the DSP clock but if you use analog I/Os it seems to be bit is not.
The reson is that the BOM for a final project can contain one oscillator less what helps to save money, and helps to avoid clock interferences. There could be another clock frequency for the DSP adjusted by its internal PLL to the cores' frequency.
Anyway, Pete, please check both the 'internal' and 'external' clock frequencies - both shall have 54.576MHz.
Best regards
Christian
> Hi Pete,
>
> The SDI debugger software is designed for use with the Software
> Architecture
> contained within the ROM of the DSP. The SDI debugger is not designed for
> use as a stand-alone, general purpose debugger. For passthru case, it's a
> stand-alone case, not required to use SDI to update firmware of EVM. You
> can
> also check your mother board version number. Rev D? RevD actually has the
> latest firmware.
>
> I'm not sure the actualy passthru code how to handle clock. I guess
> digital
> or analog input rx and tx clock are all set to slave mode and synced
> from AK4114 on mother board. There is a 24.576MHz XTAL on the mother
> board.
> It's the XTAL source of above AK4114. It's also connected to EXT of
> daughter
> board. If we set daughter's EXT as OSC source, that means DSP also drived
> by
> this 24.576 XTAL. But if select INT INT as OSC source, it should also work
> properly. It's strange, need more investigation.
> --
> Best Regards.
>
> Johnny Chen
>
> 2009/8/3, p...@blueyonder.co.uk :
> >
> >
> >
> > Hi Guys
> >
> > I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
> >
> > I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
> >
> > I just get a distorted sound on the analogue output that is loosely
> based
> > on the Analogue input signal.
> >
> > I can get a perfectly clean signal out if I change the OSC SEL links to
> EXT
> > instead of INT and INT and add link AUX1 on JP11 (Which changes the SR
> to
> > 96kHz instead of 48kHz).
> >
> > I have not yet done the SDI version 2.5 update the the firmware.
> >
> > Does anyone know if this update is needed to run the Audio Pass Through
> > Demo or if it is only required when I come to using the SDI software
> it's
> > self?
> >
> > Thanks for your help
> >
> > Pete Johnston
> >
> >
the daughterboard gets an identical clock frequency both with the internal oscillator plus chrystal or external oscilator chip. The external configuration should work without any problem. If not so, please use an oscilloscope probe to check the clock signal.
Pete uses a rev. D motherboard anyway so there is no need for an update. We discussed the jumper settings for both the motherboard and daughterboard already. The strange thing is that he has to jumper AUX1 for the analog input as well what is not listed in thedocumentation as a valid mode setting.
The passthru clock uses a signal derived from the 24.576MHz master clock for the AD and DA converters and a clock derived from the Receiver PLL if you use a digital input. The audio clock doesn't need to by in sync to the DSP clock but if you use analog I/Os it seems to be bit is not.
The reson is that the BOM for a final project can contain one oscillator less what helps to save money, and helps to avoid clock interferences. There could be another clock frequency for the DSP adjusted by its internal PLL to the cores' frequency.
Anyway, Pete, please check both the 'internal' and 'external' clock frequencies - both shall have 54.576MHz.
Best regards
Christian
> Hi Pete,
>
> The SDI debugger software is designed for use with the Software
> Architecture
> contained within the ROM of the DSP. The SDI debugger is not designed for
> use as a stand-alone, general purpose debugger. For passthru case, it's a
> stand-alone case, not required to use SDI to update firmware of EVM. You
> can
> also check your mother board version number. Rev D? RevD actually has the
> latest firmware.
>
> I'm not sure the actualy passthru code how to handle clock. I guess
> digital
> or analog input rx and tx clock are all set to slave mode and synced
> from AK4114 on mother board. There is a 24.576MHz XTAL on the mother
> board.
> It's the XTAL source of above AK4114. It's also connected to EXT of
> daughter
> board. If we set daughter's EXT as OSC source, that means DSP also drived
> by
> this 24.576 XTAL. But if select INT INT as OSC source, it should also work
> properly. It's strange, need more investigation.
> --
> Best Regards.
>
> Johnny Chen
>
> 2009/8/3, p...@blueyonder.co.uk :
> >
> >
> >
> > Hi Guys
> >
> > I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
> >
> > I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
> >
> > I just get a distorted sound on the analogue output that is loosely
> based
> > on the Analogue input signal.
> >
> > I can get a perfectly clean signal out if I change the OSC SEL links to
> EXT
> > instead of INT and INT and add link AUX1 on JP11 (Which changes the SR
> to
> > 96kHz instead of 48kHz).
> >
> > I have not yet done the SDI version 2.5 update the the firmware.
> >
> > Does anyone know if this update is needed to run the Audio Pass Through
> > Demo or if it is only required when I come to using the SDI software
> it's
> > self?
> >
> > Thanks for your help
> >
> > Pete Johnston
> >
> >
Reply by ●August 9, 20092009-08-09
Hi Pete an Johnny,
once you got the passthru example running from the daughterboard flash memory please tell me how you used the debugger an run a working code example. I couldn't manage this up to now using both Suite56 and Symphony Studio.
I have a dual core project available for the 56720 that works using a command batch file from the debugger. If you do the same commands stepwise, the output is muted. Using Symphony Studio with syncronized cores doesn't work as well.
If someone is interested to have a trial I can forward the entire project (720passthru_FTF_20070619 provided by Freescale) to him. Unfortunately it is not possible to attach it to this posting, so please contact me directly.
Best regards
Christian
Hi Guys
>
>I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>
>I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>
>I just get a distorted sound on the analogue output that is loosely based on the Analogue input signal.
>
>I can get a perfectly clean signal out if I change the OSC SEL links to EXT instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to 96kHz instead of 48kHz).
>
>I have not yet done the SDI version 2.5 update the the firmware.
>
>Does anyone know if this update is needed to run the Audio Pass Through Demo or if it is only required when I come to using the SDI software it's self?
>
>Thanks for your help
>
>Pete Johnston
once you got the passthru example running from the daughterboard flash memory please tell me how you used the debugger an run a working code example. I couldn't manage this up to now using both Suite56 and Symphony Studio.
I have a dual core project available for the 56720 that works using a command batch file from the debugger. If you do the same commands stepwise, the output is muted. Using Symphony Studio with syncronized cores doesn't work as well.
If someone is interested to have a trial I can forward the entire project (720passthru_FTF_20070619 provided by Freescale) to him. Unfortunately it is not possible to attach it to this posting, so please contact me directly.
Best regards
Christian
Hi Guys
>
>I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>
>I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>
>I just get a distorted sound on the analogue output that is loosely based on the Analogue input signal.
>
>I can get a perfectly clean signal out if I change the OSC SEL links to EXT instead of INT and INT and add link AUX1 on JP11 (Which changes the SR to 96kHz instead of 48kHz).
>
>I have not yet done the SDI version 2.5 update the the firmware.
>
>Does anyone know if this update is needed to run the Audio Pass Through Demo or if it is only required when I come to using the SDI software it's self?
>
>Thanks for your help
>
>Pete Johnston
Reply by ●August 9, 20092009-08-09
Hi Pete an Johnny,
once you got the passthru example running from the daughterboard flash memory please tell me how you used the debugger an run a working code example. I couldn't manage this up to now using both Suite56 and Symphony Studio.
I have a dual core project available for the 56720 that works using a command batch file from the debugger. If you do the same commands stepwise, the output is muted. Using Symphony Studio with syncronized cores doesn't work as well.
If someone is interested to have a trial I can forward the entire project (720passthru_FTF_20070619 provided by Freescale) to him. Unfortunately it is not possible to attach it to this posting, so please contact me directly.
Best regards
Christian
-------- Original-Nachricht --------
> Datum: Thu, 6 Aug 2009 23:54:34 +0800
> Von: Johnny Chen
> An: p...@blueyonder.co.uk
> CC: m...
> Betreff: Re: [motoroladsp] Nubbie DSPAUDIOEVM 56720 Pass Through distortion
> Hi Pete,
>
> The SDI debugger software is designed for use with the Software
> Architecture
> contained within the ROM of the DSP. The SDI debugger is not designed for
> use as a stand-alone, general purpose debugger. For passthru case, it's a
> stand-alone case, not required to use SDI to update firmware of EVM. You
> can
> also check your mother board version number. Rev D? RevD actually has the
> latest firmware.
>
> I'm not sure the actualy passthru code how to handle clock. I guess
> digital
> or analog input rx and tx clock are all set to slave mode and synced
> from AK4114 on mother board. There is a 24.576MHz XTAL on the mother
> board.
> It's the XTAL source of above AK4114. It's also connected to EXT of
> daughter
> board. If we set daughter's EXT as OSC source, that means DSP also drived
> by
> this 24.576 XTAL. But if select INT INT as OSC source, it should also work
> properly. It's strange, need more investigation.
> --
> Best Regards.
>
> Johnny Chen
>
> 2009/8/3, p...@blueyonder.co.uk :
> >
> >
> >
> > Hi Guys
> >
> > I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
> >
> > I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
> >
> > I just get a distorted sound on the analogue output that is loosely
> based
> > on the Analogue input signal.
> >
> > I can get a perfectly clean signal out if I change the OSC SEL links to
> EXT
> > instead of INT and INT and add link AUX1 on JP11 (Which changes the SR
> to
> > 96kHz instead of 48kHz).
> >
> > I have not yet done the SDI version 2.5 update the the firmware.
> >
> > Does anyone know if this update is needed to run the Audio Pass Through
> > Demo or if it is only required when I come to using the SDI software
> it's
> > self?
> >
> > Thanks for your help
> >
> > Pete Johnston
> >
> >
once you got the passthru example running from the daughterboard flash memory please tell me how you used the debugger an run a working code example. I couldn't manage this up to now using both Suite56 and Symphony Studio.
I have a dual core project available for the 56720 that works using a command batch file from the debugger. If you do the same commands stepwise, the output is muted. Using Symphony Studio with syncronized cores doesn't work as well.
If someone is interested to have a trial I can forward the entire project (720passthru_FTF_20070619 provided by Freescale) to him. Unfortunately it is not possible to attach it to this posting, so please contact me directly.
Best regards
Christian
-------- Original-Nachricht --------
> Datum: Thu, 6 Aug 2009 23:54:34 +0800
> Von: Johnny Chen
> An: p...@blueyonder.co.uk
> CC: m...
> Betreff: Re: [motoroladsp] Nubbie DSPAUDIOEVM 56720 Pass Through distortion
> Hi Pete,
>
> The SDI debugger software is designed for use with the Software
> Architecture
> contained within the ROM of the DSP. The SDI debugger is not designed for
> use as a stand-alone, general purpose debugger. For passthru case, it's a
> stand-alone case, not required to use SDI to update firmware of EVM. You
> can
> also check your mother board version number. Rev D? RevD actually has the
> latest firmware.
>
> I'm not sure the actualy passthru code how to handle clock. I guess
> digital
> or analog input rx and tx clock are all set to slave mode and synced
> from AK4114 on mother board. There is a 24.576MHz XTAL on the mother
> board.
> It's the XTAL source of above AK4114. It's also connected to EXT of
> daughter
> board. If we set daughter's EXT as OSC source, that means DSP also drived
> by
> this 24.576 XTAL. But if select INT INT as OSC source, it should also work
> properly. It's strange, need more investigation.
> --
> Best Regards.
>
> Johnny Chen
>
> 2009/8/3, p...@blueyonder.co.uk :
> >
> >
> >
> > Hi Guys
> >
> > I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
> >
> > I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
> >
> > I just get a distorted sound on the analogue output that is loosely
> based
> > on the Analogue input signal.
> >
> > I can get a perfectly clean signal out if I change the OSC SEL links to
> EXT
> > instead of INT and INT and add link AUX1 on JP11 (Which changes the SR
> to
> > 96kHz instead of 48kHz).
> >
> > I have not yet done the SDI version 2.5 update the the firmware.
> >
> > Does anyone know if this update is needed to run the Audio Pass Through
> > Demo or if it is only required when I come to using the SDI software
> it's
> > self?
> >
> > Thanks for your help
> >
> > Pete Johnston
> >
> >
Reply by ●August 9, 20092009-08-09
Hi Guys
I've got some new info that may through some light on my problem and may
also link the two problems together.
I tried the thru demo feeding it with SPDIF and got a clearer picture of
what is going on.
This is all with the osc sel set to EXT and it makes no difference if I
use RX3 or RX4
Every time I press the reset button on the board I get a random
different result.
What is happening is each time I get a different gain (always an
increase of gain) but it is always a multiple of 6 dB (x2), in other
words one press of the reset may give me a gain of 18 dB another could
give me gain of 96 dB another might give a gain of 6 dB. I have to
attenuate the signal I am sending before I send it to the SPDIF input
of the board or I just get a buzzing white noise like sounds due to the
wrap around effect of this huge sine wave.
I can get a 0 dB gain by repeatedly pressing the reset button (and
keeping my fingers crossed) but it takes more that 100 presses on
average to get it in this state. When I do get it in this state the
signal going through is perfectly clean. I thought it would average out
to 24 presses to get a good one but it defiantly needs more than 100
presses.
This is the same problem I was getting with the analogue input but the
noise floor was hiding what was really going on when the test signal was
attenuated by large amounts.
So it seems that my problem is that the serial digital data is not being
frame locked correctly and that the frame start is being being choose by
what ever point it is at, at the time I press the reset button and get
the program running.
I'm not sure why it always works correctly every time when I link up for
96kHz analogue input and feed analogue in.
Maybe this is connected to the INT/INT osc sel never working.
I'm not yet sure of the framing mechanism and without a scope it may be
hard to trace the problem, but if you have any ideas I will be most
grateful.
Thanks
Pete
Hi Christian and Johnny
The AIN1 96KHz (AUX 1,3 and5) option is in the attached document page
2-6 Table 2-2.
I was hoping that I could run at 48KHz to get more processing power but
this option doesn't work for me. I will try feeding it with SPDIF input
and see how that one works.
The problem I get with AUX 3 and 5 is excessive input gain so there is
probably a short between some pins of the A to D. I'll have to find the
chip pin out to see what could have this effect.
As far as the clock is concerned it is the EXT that works fine and the
INT that has the problem. I'm afraid test gear is a bit thin on the
ground here so I'm having to do it by guess work. The effect is as if
the clocks are not locked when I set it to INT as I am getting a beating
effect around 1 Hz.
I have re flashed both the config and the debug chips and it is exactly
the same so I think you were right about the firmware being up to date
already.
By the way the re-flashing required being a bit creative with the
instructions. When the instructions that you get with the firmware says
link DEBUG MPU on JP7 not JP8 it should say on JP8 as well. And when it
says the BAUD rate for the CONFIG MPU is 19200 it should say 9600. The
attached document is a bit closer to the truth.
I'm thinking maybe I should just go with what works at the moment and
get on to the next stage of actually trying to program it.
I could maybe try your project Christian.
Thanks for your help Guys
Pete
www.bantusound.com
Christian Langen wrote:
>Hi Pete and Johnny,file:///Users/pete/Desktop/**Downloads**/DSP56720DBUG.pdf the daughterboard gets an identical clock frequency both with the internal oscillator plus chrystal or external oscilator chip. The external configuration should work without any problem. If not so, please use an oscilloscope probe to check the clock signal.
>
>Pete uses a rev. D motherboard anyway so there is no need for an update. We discussed the jumper settings for both the motherboard and daughterboard already. The strange thing is that he has to jumper AUX1 for the analog input as well what is not listed in thedocumentation as a valid mode setting.
>
>The passthru clock uses a signal derived from the 24.576MHz master clock for the AD and DA converters and a clock derived from the Receiver PLL if you use a digital input. The audio clock doesn't need to by in sync to the DSP clock but if you use analog I/Os it seems to be bit is not.
>
>The reson is that the BOM for a final project can contain one oscillator less what helps to save money, and helps to avoid clock interferences. There could be another clock frequency for the DSP adjusted by its internal PLL to the cores' frequency.
>
>Anyway, Pete, please check both the 'internal' and 'external' clock frequencies - both shall have 54.576MHz.
>
>Best regards
>
>Christian
>
>
>
>>Hi Pete,
>>
>>The SDI debugger software is designed for use with the Software
>>Architecture
>>contained within the ROM of the DSP. The SDI debugger is not designed for
>>use as a stand-alone, general purpose debugger. For passthru case, it's a
>>stand-alone case, not required to use SDI to update firmware of EVM. You
>>can
>>also check your mother board version number. Rev D? RevD actually has the
>>latest firmware.
>>
>>I'm not sure the actualy passthru code how to handle clock. I guess
>>digital
>>or analog input rx and tx clock are all set to slave mode and synced
>>from AK4114 on mother board. There is a 24.576MHz XTAL on the mother
>>board.
>>It's the XTAL source of above AK4114. It's also connected to EXT of
>>daughter
>>board. If we set daughter's EXT as OSC source, that means DSP also drived
>>by
>>this 24.576 XTAL. But if select INT INT as OSC source, it should also work
>>properly. It's strange, need more investigation.
>>--
>>Best Regards.
>>
>>Johnny Chen
>>
>>2009/8/3, p...@blueyonder.co.uk :
>>
>>
>>>Hi Guys
>>>
>>>I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>>>
>>>I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>>>
>>>I just get a distorted sound on the analogue output that is loosely
>>>
>>>
>>based
>>
>>
>>>on the Analogue input signal.
>>>
>>>I can get a perfectly clean signal out if I change the OSC SEL links to
>>>
>>>
>>EXT
>>
>>
>>>instead of INT and INT and add link AUX1 on JP11 (Which changes the SR
>>>
>>>
>>to
>>
>>
>>>96kHz instead of 48kHz).
>>>
>>>I have not yet done the SDI version 2.5 update the the firmware.
>>>
>>>Does anyone know if this update is needed to run the Audio Pass Through
>>>Demo or if it is only required when I come to using the SDI software
>>>
>>>
>>it's
>>
>>
>>>self?
>>>
>>>Thanks for your help
>>>
>>>Pete Johnston
>>>
>>>
>>>
>>>
>
I've got some new info that may through some light on my problem and may
also link the two problems together.
I tried the thru demo feeding it with SPDIF and got a clearer picture of
what is going on.
This is all with the osc sel set to EXT and it makes no difference if I
use RX3 or RX4
Every time I press the reset button on the board I get a random
different result.
What is happening is each time I get a different gain (always an
increase of gain) but it is always a multiple of 6 dB (x2), in other
words one press of the reset may give me a gain of 18 dB another could
give me gain of 96 dB another might give a gain of 6 dB. I have to
attenuate the signal I am sending before I send it to the SPDIF input
of the board or I just get a buzzing white noise like sounds due to the
wrap around effect of this huge sine wave.
I can get a 0 dB gain by repeatedly pressing the reset button (and
keeping my fingers crossed) but it takes more that 100 presses on
average to get it in this state. When I do get it in this state the
signal going through is perfectly clean. I thought it would average out
to 24 presses to get a good one but it defiantly needs more than 100
presses.
This is the same problem I was getting with the analogue input but the
noise floor was hiding what was really going on when the test signal was
attenuated by large amounts.
So it seems that my problem is that the serial digital data is not being
frame locked correctly and that the frame start is being being choose by
what ever point it is at, at the time I press the reset button and get
the program running.
I'm not sure why it always works correctly every time when I link up for
96kHz analogue input and feed analogue in.
Maybe this is connected to the INT/INT osc sel never working.
I'm not yet sure of the framing mechanism and without a scope it may be
hard to trace the problem, but if you have any ideas I will be most
grateful.
Thanks
Pete
Hi Christian and Johnny
The AIN1 96KHz (AUX 1,3 and5) option is in the attached document page
2-6 Table 2-2.
I was hoping that I could run at 48KHz to get more processing power but
this option doesn't work for me. I will try feeding it with SPDIF input
and see how that one works.
The problem I get with AUX 3 and 5 is excessive input gain so there is
probably a short between some pins of the A to D. I'll have to find the
chip pin out to see what could have this effect.
As far as the clock is concerned it is the EXT that works fine and the
INT that has the problem. I'm afraid test gear is a bit thin on the
ground here so I'm having to do it by guess work. The effect is as if
the clocks are not locked when I set it to INT as I am getting a beating
effect around 1 Hz.
I have re flashed both the config and the debug chips and it is exactly
the same so I think you were right about the firmware being up to date
already.
By the way the re-flashing required being a bit creative with the
instructions. When the instructions that you get with the firmware says
link DEBUG MPU on JP7 not JP8 it should say on JP8 as well. And when it
says the BAUD rate for the CONFIG MPU is 19200 it should say 9600. The
attached document is a bit closer to the truth.
I'm thinking maybe I should just go with what works at the moment and
get on to the next stage of actually trying to program it.
I could maybe try your project Christian.
Thanks for your help Guys
Pete
www.bantusound.com
Christian Langen wrote:
>Hi Pete and Johnny,file:///Users/pete/Desktop/**Downloads**/DSP56720DBUG.pdf the daughterboard gets an identical clock frequency both with the internal oscillator plus chrystal or external oscilator chip. The external configuration should work without any problem. If not so, please use an oscilloscope probe to check the clock signal.
>
>Pete uses a rev. D motherboard anyway so there is no need for an update. We discussed the jumper settings for both the motherboard and daughterboard already. The strange thing is that he has to jumper AUX1 for the analog input as well what is not listed in thedocumentation as a valid mode setting.
>
>The passthru clock uses a signal derived from the 24.576MHz master clock for the AD and DA converters and a clock derived from the Receiver PLL if you use a digital input. The audio clock doesn't need to by in sync to the DSP clock but if you use analog I/Os it seems to be bit is not.
>
>The reson is that the BOM for a final project can contain one oscillator less what helps to save money, and helps to avoid clock interferences. There could be another clock frequency for the DSP adjusted by its internal PLL to the cores' frequency.
>
>Anyway, Pete, please check both the 'internal' and 'external' clock frequencies - both shall have 54.576MHz.
>
>Best regards
>
>Christian
>
>
>
>>Hi Pete,
>>
>>The SDI debugger software is designed for use with the Software
>>Architecture
>>contained within the ROM of the DSP. The SDI debugger is not designed for
>>use as a stand-alone, general purpose debugger. For passthru case, it's a
>>stand-alone case, not required to use SDI to update firmware of EVM. You
>>can
>>also check your mother board version number. Rev D? RevD actually has the
>>latest firmware.
>>
>>I'm not sure the actualy passthru code how to handle clock. I guess
>>digital
>>or analog input rx and tx clock are all set to slave mode and synced
>>from AK4114 on mother board. There is a 24.576MHz XTAL on the mother
>>board.
>>It's the XTAL source of above AK4114. It's also connected to EXT of
>>daughter
>>board. If we set daughter's EXT as OSC source, that means DSP also drived
>>by
>>this 24.576 XTAL. But if select INT INT as OSC source, it should also work
>>properly. It's strange, need more investigation.
>>--
>>Best Regards.
>>
>>Johnny Chen
>>
>>2009/8/3, p...@blueyonder.co.uk :
>>
>>
>>>Hi Guys
>>>
>>>I've just purchased the DSPX72YDBZE and DSPAUDIOEVMMB1E.
>>>
>>>I've tried the Audio Pass Through Demo linking up as per DSP56720BUG.pdf
>>>
>>>I just get a distorted sound on the analogue output that is loosely
>>>
>>>
>>based
>>
>>
>>>on the Analogue input signal.
>>>
>>>I can get a perfectly clean signal out if I change the OSC SEL links to
>>>
>>>
>>EXT
>>
>>
>>>instead of INT and INT and add link AUX1 on JP11 (Which changes the SR
>>>
>>>
>>to
>>
>>
>>>96kHz instead of 48kHz).
>>>
>>>I have not yet done the SDI version 2.5 update the the firmware.
>>>
>>>Does anyone know if this update is needed to run the Audio Pass Through
>>>Demo or if it is only required when I come to using the SDI software
>>>
>>>
>>it's
>>
>>
>>>self?
>>>
>>>Thanks for your help
>>>
>>>Pete Johnston
>>>
>>>
>>>
>>>
>
Reply by ●September 15, 20092009-09-15
Hi all,
I got a chance to go through the passthru code in the E2PROM on the 720ADB.
I think I have got the root cause of issues.
1. PCTL setting in the code is 0x2B40C1, means 200.704MHz which duty cycles
may not be 50%. That cause clock difference for EXT and INT. It should be
set to 2B60C2 (199.680MHz). Have provided that passthru code can work
properly while PCTL+60C2, with jumper setting list as below as well.
2.The jumpers setting in the UG is not correct.
HCKT of ESAI TX is connected to HCKR_1 of ESAI_1 RX. SCKT/FST of ESAI TX is
driven by HCKT, not syncing to SCKR_1/FSR_1 of ESAI_1 RX as TCCR is
6c0301. So jumpers of JP1 should not be all closed.
There are several versions in E2PROM. For the version support passthru
output from core1, jumper I,K also should be removed.
Jumper A is not suitable for 96KHz case. It should be removed with B jumper
closed. MCLK is from RX02. For 48KHz input, it will be 12.288MHz. For 96KHz,
it will be 24.576MHz, just keep ratio MCLK(HCKR/HCKT_1) = 256fs.
Correct settings please refer to below.
Jumper configuration:
Mother board:
JP8: PPI Port closed
JP4: all "4114" are closed, others open
JP10: all closed
Daughter card:
JP15: two INT closed
JP1: HCKR0-HCKT0 closed, others open
JP3: all open
Jumpers on B, C, D, E, F, G, H, J, M, N, O, P, Q, T
SW1:0100 0110(pin is from 12345678),boot mode 6 for core0 from EEPROM,I2C as
master. boot mode 4 for core1, boot from other DSP.
SW2:I2C on,SPI off.
AOUT1/AOUT2/AOUT3 are output from core0.
AOUT4/AOUT5/AOUT6 are output from core1 if it's support in this version.
To debug two core dsp by suite563 tool.
1. Open gds56300.
2. In the command window, send commands below to cofig and connect two
cores.
device dv0 tms0 pos0
device dv1 tms0 pos1
3. send "device dv0" to set core0 as default, then you can open memory and
register windows for accessing core0.
You can also send "device dv1" to selec core1 as default core.
4. "force dv0..1 r" is used to reset dsp both two cores
5. "force dv0..1 b" is used to stop both two cores
6."go dv0..1" is used to run two cores.
Please note, when debugging two cores dsp, be sure to stop both two cores
before you stepping the code. Otherwise, the code will not work properly.
Likewise, be sure to run both two cores instead instead of simple "go".
--
Best Regards.
Johnny Chen
I got a chance to go through the passthru code in the E2PROM on the 720ADB.
I think I have got the root cause of issues.
1. PCTL setting in the code is 0x2B40C1, means 200.704MHz which duty cycles
may not be 50%. That cause clock difference for EXT and INT. It should be
set to 2B60C2 (199.680MHz). Have provided that passthru code can work
properly while PCTL+60C2, with jumper setting list as below as well.
2.The jumpers setting in the UG is not correct.
HCKT of ESAI TX is connected to HCKR_1 of ESAI_1 RX. SCKT/FST of ESAI TX is
driven by HCKT, not syncing to SCKR_1/FSR_1 of ESAI_1 RX as TCCR is
6c0301. So jumpers of JP1 should not be all closed.
There are several versions in E2PROM. For the version support passthru
output from core1, jumper I,K also should be removed.
Jumper A is not suitable for 96KHz case. It should be removed with B jumper
closed. MCLK is from RX02. For 48KHz input, it will be 12.288MHz. For 96KHz,
it will be 24.576MHz, just keep ratio MCLK(HCKR/HCKT_1) = 256fs.
Correct settings please refer to below.
Jumper configuration:
Mother board:
JP8: PPI Port closed
JP4: all "4114" are closed, others open
JP10: all closed
Daughter card:
JP15: two INT closed
JP1: HCKR0-HCKT0 closed, others open
JP3: all open
Jumpers on B, C, D, E, F, G, H, J, M, N, O, P, Q, T
SW1:0100 0110(pin is from 12345678),boot mode 6 for core0 from EEPROM,I2C as
master. boot mode 4 for core1, boot from other DSP.
SW2:I2C on,SPI off.
AOUT1/AOUT2/AOUT3 are output from core0.
AOUT4/AOUT5/AOUT6 are output from core1 if it's support in this version.
To debug two core dsp by suite563 tool.
1. Open gds56300.
2. In the command window, send commands below to cofig and connect two
cores.
device dv0 tms0 pos0
device dv1 tms0 pos1
3. send "device dv0" to set core0 as default, then you can open memory and
register windows for accessing core0.
You can also send "device dv1" to selec core1 as default core.
4. "force dv0..1 r" is used to reset dsp both two cores
5. "force dv0..1 b" is used to stop both two cores
6."go dv0..1" is used to run two cores.
Please note, when debugging two cores dsp, be sure to stop both two cores
before you stepping the code. Otherwise, the code will not work properly.
Likewise, be sure to run both two cores instead instead of simple "go".
--
Best Regards.
Johnny Chen
Reply by ●September 16, 20092009-09-16
Hi Johnny
You are truly brilliant.
I did find that it worked with B linked instead of A simply by going through every combination, but I had no idea why and was not sure that what I was doing the was the right thing or why it worked.
I don't yet fully understand the details of what you are saying but I will and will make understanding this my priority.
You have found it and I now feel confident into going onto the next stage.
Do you Have access to the source code for the Passthru code or have you read the assembly off the chip? This code would be the perfect starting point for me.
Thanks so much
Pete Johnston
You are truly brilliant.
I did find that it worked with B linked instead of A simply by going through every combination, but I had no idea why and was not sure that what I was doing the was the right thing or why it worked.
I don't yet fully understand the details of what you are saying but I will and will make understanding this my priority.
You have found it and I now feel confident into going onto the next stage.
Do you Have access to the source code for the Passthru code or have you read the assembly off the chip? This code would be the perfect starting point for me.
Thanks so much
Pete Johnston
Reply by ●September 16, 20092009-09-16
Hi Johnny,
thank you for the report, I tried to follow your instructions using the DSPB725DB2E daughterboard (the '725 core is identical to the '720). The problem is that I can download and run the demonstration code using the command script 'passthru_720.cmd' it resets coth cores loads the codes and starts them without any problem. If I try to do this stepwise I have no output signal. The jumper settings are o.k. and according to your suggestions since I can get all output signals either booting from the E2PROM or running the 'passthru_720.cmd' macro.
Anyway, even trying to reset, break and run both cores synchronously following your instructions did not help to run my demonstration code.
The benefit of the '725 is that it can run higher clock frequencies than the '720 (up to 250MHz) so I had no problem running the code even with a higher core clock frequency.
By the way, which demonstration code do you use? Could you please post me the code example to try this? I use the 720passthru_FTF_20070619 package.
; passthru_720.cmd
device dv0 tms0 pos0
device dv1 tms0 pos1
device dv0
force r
wmemory p $0; 0..ffffff, pe, pi or pr depending upon address and omr value
wregister core
wasm
change pc 0
load passthru_core0.cld
;step
go
device dv1
wmemory p $0; 0..ffffff, pe, pi or pr depending upon address and omr value
wregister core
wasm
change pc 0
load passthru_core1.cld
;step
go
Best regards
Christian
> Hi all,
>
> I got a chance to go through the passthru code in the E2PROM on the
> 720ADB.
> I think I have got the root cause of issues.
> 1. PCTL setting in the code is 0x2B40C1, means 200.704MHz which duty
> cycles
> may not be 50%. That cause clock difference for EXT and INT. It should be
> set to 2B60C2 (199.680MHz). Have provided that passthru code can work
> properly while PCTL+60C2, with jumper setting list as below as well.
>
> 2.The jumpers setting in the UG is not correct.
> HCKT of ESAI TX is connected to HCKR_1 of ESAI_1 RX. SCKT/FST of ESAI TX
> is
> driven by HCKT, not syncing to SCKR_1/FSR_1 of ESAI_1 RX as TCCR is
> 6c0301. So jumpers of JP1 should not be all closed.
> There are several versions in E2PROM. For the version support passthru
> output from core1, jumper I,K also should be removed.
> Jumper A is not suitable for 96KHz case. It should be removed with B
> jumper
> closed. MCLK is from RX02. For 48KHz input, it will be 12.288MHz. For
> 96KHz,
> it will be 24.576MHz, just keep ratio MCLK(HCKR/HCKT_1) = 256fs.
> Correct settings please refer to below.
>
> Jumper configuration:
> Mother board:
> JP8: PPI Port closed
> JP4: all "4114" are closed, others open
> JP10: all closed
>
> Daughter card:
> JP15: two INT closed
> • JP1: HCKR0-HCKT0 closed, others open
> • JP3: all open
> • Jumpers on B, C, D, E, F, G, H, J, M, N, O, P, Q, T
> SW1:0100 0110(pin is from 12345678),boot mode 6 for core0 from EEPROM,I2C
> as
> master. boot mode 4 for core1, boot from other DSP.
> SW2:I2C on,SPI off.
>
> AOUT1/AOUT2/AOUT3 are output from core0.
> AOUT4/AOUT5/AOUT6 are output from core1 if it's support in this version.
> To debug two core dsp by suite563 tool.
>
> 1. Open gds56300.
> 2. In the command window, send commands below to cofig and connect two
> cores.
> device dv0 tms0 pos0
> device dv1 tms0 pos1
> 3. send "device dv0" to set core0 as default, then you can open memory and
> register windows for accessing core0.
> You can also send "device dv1" to selec core1 as default core.
> 4. "force dv0..1 r" is used to reset dsp both two cores
> 5. "force dv0..1 b" is used to stop both two cores
> 6."go dv0..1" is used to run two cores.
>
> Please note, when debugging two cores dsp, be sure to stop both two cores
> before you stepping the code. Otherwise, the code will not work properly.
> Likewise, be sure to run both two cores instead instead of simple "go".
> --
> Best Regards.
>
> Johnny Chen
thank you for the report, I tried to follow your instructions using the DSPB725DB2E daughterboard (the '725 core is identical to the '720). The problem is that I can download and run the demonstration code using the command script 'passthru_720.cmd' it resets coth cores loads the codes and starts them without any problem. If I try to do this stepwise I have no output signal. The jumper settings are o.k. and according to your suggestions since I can get all output signals either booting from the E2PROM or running the 'passthru_720.cmd' macro.
Anyway, even trying to reset, break and run both cores synchronously following your instructions did not help to run my demonstration code.
The benefit of the '725 is that it can run higher clock frequencies than the '720 (up to 250MHz) so I had no problem running the code even with a higher core clock frequency.
By the way, which demonstration code do you use? Could you please post me the code example to try this? I use the 720passthru_FTF_20070619 package.
; passthru_720.cmd
device dv0 tms0 pos0
device dv1 tms0 pos1
device dv0
force r
wmemory p $0; 0..ffffff, pe, pi or pr depending upon address and omr value
wregister core
wasm
change pc 0
load passthru_core0.cld
;step
go
device dv1
wmemory p $0; 0..ffffff, pe, pi or pr depending upon address and omr value
wregister core
wasm
change pc 0
load passthru_core1.cld
;step
go
Best regards
Christian
> Hi all,
>
> I got a chance to go through the passthru code in the E2PROM on the
> 720ADB.
> I think I have got the root cause of issues.
> 1. PCTL setting in the code is 0x2B40C1, means 200.704MHz which duty
> cycles
> may not be 50%. That cause clock difference for EXT and INT. It should be
> set to 2B60C2 (199.680MHz). Have provided that passthru code can work
> properly while PCTL+60C2, with jumper setting list as below as well.
>
> 2.The jumpers setting in the UG is not correct.
> HCKT of ESAI TX is connected to HCKR_1 of ESAI_1 RX. SCKT/FST of ESAI TX
> is
> driven by HCKT, not syncing to SCKR_1/FSR_1 of ESAI_1 RX as TCCR is
> 6c0301. So jumpers of JP1 should not be all closed.
> There are several versions in E2PROM. For the version support passthru
> output from core1, jumper I,K also should be removed.
> Jumper A is not suitable for 96KHz case. It should be removed with B
> jumper
> closed. MCLK is from RX02. For 48KHz input, it will be 12.288MHz. For
> 96KHz,
> it will be 24.576MHz, just keep ratio MCLK(HCKR/HCKT_1) = 256fs.
> Correct settings please refer to below.
>
> Jumper configuration:
> Mother board:
> JP8: PPI Port closed
> JP4: all "4114" are closed, others open
> JP10: all closed
>
> Daughter card:
> JP15: two INT closed
> • JP1: HCKR0-HCKT0 closed, others open
> • JP3: all open
> • Jumpers on B, C, D, E, F, G, H, J, M, N, O, P, Q, T
> SW1:0100 0110(pin is from 12345678),boot mode 6 for core0 from EEPROM,I2C
> as
> master. boot mode 4 for core1, boot from other DSP.
> SW2:I2C on,SPI off.
>
> AOUT1/AOUT2/AOUT3 are output from core0.
> AOUT4/AOUT5/AOUT6 are output from core1 if it's support in this version.
> To debug two core dsp by suite563 tool.
>
> 1. Open gds56300.
> 2. In the command window, send commands below to cofig and connect two
> cores.
> device dv0 tms0 pos0
> device dv1 tms0 pos1
> 3. send "device dv0" to set core0 as default, then you can open memory and
> register windows for accessing core0.
> You can also send "device dv1" to selec core1 as default core.
> 4. "force dv0..1 r" is used to reset dsp both two cores
> 5. "force dv0..1 b" is used to stop both two cores
> 6."go dv0..1" is used to run two cores.
>
> Please note, when debugging two cores dsp, be sure to stop both two cores
> before you stepping the code. Otherwise, the code will not work properly.
> Likewise, be sure to run both two cores instead instead of simple "go".
> --
> Best Regards.
>
> Johnny Chen
