Hi Johnny,

this stange behaviour is reasoned by starting a second debug monitor session while the first is not terminated. You can see this in the debug monitor window. The second connection sticks at 10% then. So please terminate this session first before starting another one. To do so change to the debug view, terminate the connection by pushing the red 'stop' button, use the 'x' button to 'remove all terminated'.

If a debug session is started you can debug and terminate code several times without problems. You can remove the targets whilst leaving the debug connection unchanged.

The GNU debugger seems to emulate a network connection to start the debug session. I didn't research this in depth yet...

Best regards

Christian

> Hi Guys
>
> I seem to be having a problem in Symphony Studio 1.1.0 when debugging
> the Pass thru code (and the tutorial code as well for that matter).
> It sticks at Launching (10%) and stays there for hours if I let it.
> Any attempts to terminate, amount to a "terminate failed" error message
> in it continues Launching(10%).
>
> I've turned on Verbose console mode to see if I can see whats going on.
> Then I get message in the console as follows
>
> localhost:9998 Unknown error.
> "monitor" command not supported by this target.
>
> I don't know what the local host is or does. I see the option to change
> it but I don't know what I could change it to.
>
> I've done searches for "localhost" on the documentation I've got but
> can't find anything.
>
> Quitting Symphony Studio and restarting at this point is not possible as
> the workspace becomes un usable and it requiters a complete shut down of
> the PC to get back into Symphony Studio.
>
> Any ideas
>
> Thanks
>
> Pete
>
> Christian Langen wrote:
>
> >
> >
> > Hi Johnny,
> >
> > the code example you went through here seems to be the original code
> > stored in the E2PROM the daughterboards are shipped with.
> >
> > This code example works with the original jumper settings when the
> > daughtercard is taken out of the box. If we would get access on this
> > code we could use this as the desired starting point to develop our
> > own application code.
> >
> > Could you please forward this code example to us? Thanks a lot in
> advance.
> >
> > 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
> >
>

Hi Guys

I seem to be having a problem in Symphony Studio 1.1.0 when debugging
the Pass thru code (and the tutorial code as well for that matter).
It sticks at Launching (10%) and stays there for hours if I let it.
Any attempts to terminate, amount to a "terminate failed" error message
in it continues Launching(10%).

I've turned on Verbose console mode to see if I can see whats going on.
Then I get message in the console as follows

localhost:9998 Unknown error.
"monitor" command not supported by this target.

I don't know what the local host is or does. I see the option to change
it but I don't know what I could change it to.

I've done searches for "localhost" on the documentation I've got but
can't find anything.

Quitting Symphony Studio and restarting at this point is not possible as
the workspace becomes un usable and it requiters a complete shut down of
the PC to get back into Symphony Studio.

Any ideas

Thanks

Pete

Christian Langen wrote:

>
>
> Hi Johnny,
>
> the code example you went through here seems to be the original code
> stored in the E2PROM the daughterboards are shipped with.
>
> This code example works with the original jumper settings when the
> daughtercard is taken out of the box. If we would get access on this
> code we could use this as the desired starting point to develop our
> own application code.
>
> Could you please forward this code example to us? Thanks a lot in advance.
>
> 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

Hi Johnny,

the code example you went through here seems to be the original code stored in the E2PROM the daughterboards are shipped with.

This code example works with the original jumper settings when the daughtercard is taken out of the box. If we would get access on this code we could use this as the desired starting point to develop our own application code.

Could you please forward this code example to us? Thanks a lot in advance.

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

Hi Johnny,

I've tested this code example: It works if you run the *.cmd script without problems using your recommended jumper settings. If you do the instructuions stepwise with the debugger after a short noise it mutes the digital outputs and gives noise on the analog outputs. Seems to be a clocking issue.

On the other hand you never claimed that the code example described here works if load and run stepwise.

Best regards

Christian

> Hi Pete,Christian,
> Jumper B is connecting HCKR with RX02. As we know RX02 is generated by
> AKM4114. Control MCU of EVM board send commands to AKM4114 to control the
> output clocks, according to the setting of AUX5/AUX3/AUX1.
> For example,
> For 48KHz input, RX02(HCKR).288M, RX SCK(SCKR)=3.072M, RX
> FRCLK(FSR)HkHz
> For 96KHz input, RX02(HCKR)$.576M, RX SCK(SCKR)=6.144M, RX
> FRCLK(FSR)HkHz
>
> In ESAI clock setting, after checking code, we can found RCCR_1 = 080200,
> TCCR = 6c0301, RCR_1= TCR= 417d00, so RX02 fits the clock settings pretty
> well. Those clocks setting also tell us, jumpers setting in the UG is not
> correct.
>
> It seems that the jumper setting in the UG is more suitable for
> 720passthru_FTF_20070619.
>
> Attached please find the passthru code similar to E2PROM version (core1
> should set to boot mode 4). You may will get the some idea from it. You
> can
> also refer to 720passthru_FTF_20070619. (Please rename file ext name .bat_
> and .cmd_ to .bat and .cmd )
>
> Data flow is: Core0 RX --> Core0 Process -->Core0 Tx
> |------> Copy to Share memory --> Core1
> process
> --> Core1 Tx
>
> I think you can modify it to below to make full use of two cores mips and
> memory for your algorithm.
>
> Core0 RX--> Core0 Process -->Copy to share memory --> Core1 process -->
> Core1 Tx
>
> cmd file for GDS please see below:
>
> *; passthru_720_upt.cmd**
> **device dv0 tms0 pos0
> device dv1 tms0 pos1
> *
> *
> *
> *force dv0..1 r*
> *force dv0..1 b*
> *
> *
> *device dv0**
> wmemory p $0; 0..ffffff, pe, pi or pr depending upon address and omr value
> wregister core
> wasm
> change pc 0
>
> load Core01-dualcore-PassThru.cld*
> *go dv0..1*
>
> Best Regards.
>
> Johnny Chen
> 2009/9/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
> >
> > .
> >

Hi Christian,

I will try 720passthru_FTF_20070619 stepwise to see whether we have any
output signal. I have modified, please have a try on your side.

; passthru_720_upt.cmd
device dv0 tms0 pos0
device dv1 tms0 pos1

force dv0..1 r
force dv0..1 b

device dv0
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
step

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
step

go dv0..1

; following is for debugging run-timely.
force dv0..1 b
device dv0
step
step
device dv1
step
step
go dv0..1
...

Please note that my jumpers setting are dedicated for E2PROM passthru. I
think these new jumpers setting is not suitable
for 720passthru_FTF_20070619. since in FTF version, all output clocks are in
slave mode(TCCR = 0c0200), synced to input HCKR/SCKR/FSR, so JP1 and JP3 of
DaughterBoard should be closed. However the E2PROM version's output clocks
are all in master mode(TCCR = 0x6c0301)

I have tried to use commands I showed in previous mail to debug and stepwise
code boot loaded from E2PROM. It does works. Dsp can get output after "go
dv0..1". Sometimes we might get noise output. I think it is caused by rx and
tx async issue. You can see in the code there is no strict error handling
mechanism for rx/tx ping-pong buffer sync recovering from stop state.

I also tried another version which support passthru via both core0 and
core1. It's not the version burned in E2PROM, also not the passthru you
mentioned. Since this cld has included code of two cores, I just downloaded
cld into core0. Set boot mode of core1 to mode 4. The commands I showed also
work for this version, even if I stepwise in GDS tool, Dsp can get output
after "go dv0..1"
Best Regards.

Johnny Chen
2009/9/16, Christian Langen :
>
> 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 Pete,Christian,
Jumper B is connecting HCKR with RX02. As we know RX02 is generated by
AKM4114. Control MCU of EVM board send commands to AKM4114 to control the
output clocks, according to the setting of AUX5/AUX3/AUX1.
For example,
For 48KHz input, RX02(HCKR).288M, RX SCK(SCKR)=3.072M, RX
FRCLK(FSR)HkHz
For 96KHz input, RX02(HCKR)$.576M, RX SCK(SCKR)=6.144M, RX
FRCLK(FSR)HkHz

In ESAI clock setting, after checking code, we can found RCCR_1 = 080200,
TCCR = 6c0301, RCR_1= TCR= 417d00, so RX02 fits the clock settings pretty
well. Those clocks setting also tell us, jumpers setting in the UG is not
correct.

It seems that the jumper setting in the UG is more suitable for
720passthru_FTF_20070619.

Attached please find the passthru code similar to E2PROM version (core1
should set to boot mode 4). You may will get the some idea from it. You can
also refer to 720passthru_FTF_20070619. (Please rename file ext name .bat_
and .cmd_ to .bat and .cmd )

Data flow is: Core0 RX --> Core0 Process -->Core0 Tx
|------> Copy to Share memory --> Core1 process
--> Core1 Tx

I think you can modify it to below to make full use of two cores mips and
memory for your algorithm.

Core0 RX--> Core0 Process -->Copy to share memory --> Core1 process -->
Core1 Tx

cmd file for GDS please see below:

*; passthru_720_upt.cmd**
**device dv0 tms0 pos0
device dv1 tms0 pos1
*
*
*
*force dv0..1 r*
*force dv0..1 b*
*
*
*device dv0**
wmemory p $0; 0..ffffff, pe, pi or pr depending upon address and omr value
wregister core
wasm
change pc 0

load Core01-dualcore-PassThru.cld*
*go dv0..1*

Best Regards.

Johnny Chen
2009/9/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
>
> .
>

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

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

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

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
>>>
>>>
>>>
>>>
>