Nubbie DSPAUDIOEVM 56720 Pass Through distortion

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
>
> .
> Start a New Thread

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
> -- Start a New Thread

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
> >
> > .
> > Start a New Thread

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 Start a New Thread

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 Start a New Thread

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
> >
> Start a New Thread