Hi Mike,
We are using DM640-based custom boards with XDS510 PP
Emulator. During production, some of our boards do not seem to
connect with CCS while some of them do. We have checked the hardware
connections and JTAG signals of these boards with those that are
working and they seem similar. We tested the boards using SDConfig
utility and it is able to detect scan path and is able to run
diagnostics.
I just went through some of your previous posts in this forum
in the past and tried out couple of your suggestions:
1. You had suggested using XDSProbe utility. I tried using it and
when I tried setting a physical address, it kept throwing
ERROR_CTL_PORT error. The subsequent commands also failed saying the
utlity aborted. The CCS setup was done properly and I verified it in
the ccBrd0.dat file. Please let me know some simple command line
utlities using which I can check the JTAG connection.
2. You had also suggested that if the address 0 of DSP has 'garbage
values', upon release, it might not give control to emulation logic
and suggested that HPI be used for putting a 'endless loop' in
address 0 of DSP. In my board design, I dont have any provision to
do HPI booting. Moreover, I cannot put the 'endless loop' in ROM too
since I can access ROM only by running a CCS program and burning hex
data into the ROM. Hence I find myself in a deadlock situation now.
Is there any other alternate way to make DSP come out of this state?
Please let me know your suggestions.
Thanks in advance,
Kalaivani
JTAG issues.. Please help Mike
Started by ●March 17, 2008
Reply by ●March 17, 20082008-03-17
Hi Kalaivani,
these production programming problems are well-known to us too. I assume
you have connected a Flash EPROM to EMIFA and configured the DM640 to EMIFA
boot (address lines AEA[22:21] pulled up). If an empty Flash is attached,
the DSP will read all FF's which result in invalid opcodes. The DSP crashes
and emulator connection is not always possible. The same may happen in "no
boot" configuration if the internal memory contains garbage.
Since the DM640 can't be configured to HPI mode, the best option is
producing the boards with pre-programmed Flash devices. If this can't be
done, you must power cycle the DSP board and retry to connect several
times. From my experience this will succeed at least after ten or so
attempts. Then immediately program the Flash memory with a known good program.
Best Regards,
Adolf Klemenz, D.SignT
At 13:16 17.03.2008 +0000, Kalaivani.S wrote:
>Hi Mike,
>We are using DM640-based custom boards with XDS510 PP
>Emulator. During production, some of our boards do not seem to
>connect with CCS while some of them do. We have checked the hardware
>connections and JTAG signals of these boards with those that are
>working and they seem similar. We tested the boards using SDConfig
>utility and it is able to detect scan path and is able to run
>diagnostics.
>I just went through some of your previous posts in this forum
>in the past and tried out couple of your suggestions:
>1. You had suggested using XDSProbe utility. I tried using it and
>when I tried setting a physical address, it kept throwing
>ERROR_CTL_PORT error. The subsequent commands also failed saying the
>utlity aborted. The CCS setup was done properly and I verified it in
>the ccBrd0.dat file. Please let me know some simple command line
>utlities using which I can check the JTAG connection.
>2. You had also suggested that if the address 0 of DSP has 'garbage
>values', upon release, it might not give control to emulation logic
>and suggested that HPI be used for putting a 'endless loop' in
>address 0 of DSP. In my board design, I dont have any provision to
>do HPI booting. Moreover, I cannot put the 'endless loop' in ROM too
>since I can access ROM only by running a CCS program and burning hex
>data into the ROM. Hence I find myself in a deadlock situation now.
>Is there any other alternate way to make DSP come out of this state?
>
>Please let me know your suggestions.
>
>Thanks in advance,
>Kalaivani
these production programming problems are well-known to us too. I assume
you have connected a Flash EPROM to EMIFA and configured the DM640 to EMIFA
boot (address lines AEA[22:21] pulled up). If an empty Flash is attached,
the DSP will read all FF's which result in invalid opcodes. The DSP crashes
and emulator connection is not always possible. The same may happen in "no
boot" configuration if the internal memory contains garbage.
Since the DM640 can't be configured to HPI mode, the best option is
producing the boards with pre-programmed Flash devices. If this can't be
done, you must power cycle the DSP board and retry to connect several
times. From my experience this will succeed at least after ten or so
attempts. Then immediately program the Flash memory with a known good program.
Best Regards,
Adolf Klemenz, D.SignT
At 13:16 17.03.2008 +0000, Kalaivani.S wrote:
>Hi Mike,
>We are using DM640-based custom boards with XDS510 PP
>Emulator. During production, some of our boards do not seem to
>connect with CCS while some of them do. We have checked the hardware
>connections and JTAG signals of these boards with those that are
>working and they seem similar. We tested the boards using SDConfig
>utility and it is able to detect scan path and is able to run
>diagnostics.
>I just went through some of your previous posts in this forum
>in the past and tried out couple of your suggestions:
>1. You had suggested using XDSProbe utility. I tried using it and
>when I tried setting a physical address, it kept throwing
>ERROR_CTL_PORT error. The subsequent commands also failed saying the
>utlity aborted. The CCS setup was done properly and I verified it in
>the ccBrd0.dat file. Please let me know some simple command line
>utlities using which I can check the JTAG connection.
>2. You had also suggested that if the address 0 of DSP has 'garbage
>values', upon release, it might not give control to emulation logic
>and suggested that HPI be used for putting a 'endless loop' in
>address 0 of DSP. In my board design, I dont have any provision to
>do HPI booting. Moreover, I cannot put the 'endless loop' in ROM too
>since I can access ROM only by running a CCS program and burning hex
>data into the ROM. Hence I find myself in a deadlock situation now.
>Is there any other alternate way to make DSP come out of this state?
>
>Please let me know your suggestions.
>
>Thanks in advance,
>Kalaivani
Reply by ●March 17, 20082008-03-17
Kalaivani,
On 3/17/08, Kalaivani.S wrote:
> Hi Mike,
> We are using DM640-based custom boards with XDS510 PP
> Emulator. During production, some of our boards do not seem to
> connect with CCS while some of them do. We have checked the hardware
> connections and JTAG signals of these boards with those that are
> working and they seem similar. We tested the boards using SDConfig
> utility and it is able to detect scan path and is able to run
> diagnostics.
> I just went through some of your previous posts in this forum
> in the past and tried out couple of your suggestions:
> 1. You had suggested using XDSProbe utility. I tried using it and
> when I tried setting a physical address, it kept throwing
> ERROR_CTL_PORT error. The subsequent commands also failed saying the
> utlity aborted. The CCS setup was done properly and I verified it in
> the ccBrd0.dat file. Please let me know some simple command line
> utlities using which I can check the JTAG connection.
Unfortunately I do not believe that SD emulators can run xdsprobe [if
they could, they would probably document it - I am not a user of SD
emulators]. Since you seem to be addressing 'hard failures' and SD
config passes, your JTAG path is likely to be okay. Just make sure
that EMU0 and EMU1 are pulled high on pins 13 and 14 of the JTAG
connector.
> 2. You had also suggested that if the address 0 of DSP has 'garbage
> values', upon release, it might not give control to emulation logic
> and suggested that HPI be used for putting a 'endless loop' in
> address 0 of DSP. In my board design, I dont have any provision to
> do HPI booting.
You do not need a provision for HPI booting to use this technique -
you only need to be able to set the configuration so that the DSP
comes up in HPI boot mode - the DSP will set there doing nothing until
you connect the emulator. The idea is that you do this for initial
debug and then set it to ROM boot [I assume] when you get code in
flash.
> Moreover, I cannot put the 'endless loop' in ROM too
> since I can access ROM only by running a CCS program and burning hex
> data into the ROM. Hence I find myself in a deadlock situation now.
> Is there any other alternate way to make DSP come out of this state?
I hope that you can access the EMIF connections to temporarily tweak
the pullup/pulldowns [or FPGA] to adjust the boot mode.
Some board design thoughts [I realize that it is a little late for this]:
1. I like for boards to be configurable for more than 1 boot mode [you
can add a couple of pullup/pulldown resitor pads, jumpers, or jumpers
to an FPGA/CPLD that controls the boot modes].
2. For devices that support HOLD on the EMIF, you can add a provision
to assert HOLD. This tristates the EMIF - it can be used to identify
shorted traces or to provide a clever method to access a Flash device
externally.
Keep in mind that your problem coupld be something else. Check your
basics - power on reset, clock and power supplies. An erratic power
source that glitches or varies downward during power up can get the
DSP in a lockup or 'brain damaged state'. The only way that you will
catch this is to monitor the power on voltage ramp with a scope.
One troubleshooting technique is to take a couple of good boards and
check the state of everything that you can access and compare it to a
'bad board'.
Hopefully, this might get you started in the right direction.
Let us know your progress.
mikedunn
>
> Please let me know your suggestions.
>
> Thanks in advance,
> Kalaivani
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
On 3/17/08, Kalaivani.S wrote:
> Hi Mike,
> We are using DM640-based custom boards with XDS510 PP
> Emulator. During production, some of our boards do not seem to
> connect with CCS while some of them do. We have checked the hardware
> connections and JTAG signals of these boards with those that are
> working and they seem similar. We tested the boards using SDConfig
> utility and it is able to detect scan path and is able to run
> diagnostics.
> I just went through some of your previous posts in this forum
> in the past and tried out couple of your suggestions:
> 1. You had suggested using XDSProbe utility. I tried using it and
> when I tried setting a physical address, it kept throwing
> ERROR_CTL_PORT error. The subsequent commands also failed saying the
> utlity aborted. The CCS setup was done properly and I verified it in
> the ccBrd0.dat file. Please let me know some simple command line
> utlities using which I can check the JTAG connection.
Unfortunately I do not believe that SD emulators can run xdsprobe [if
they could, they would probably document it - I am not a user of SD
emulators]. Since you seem to be addressing 'hard failures' and SD
config passes, your JTAG path is likely to be okay. Just make sure
that EMU0 and EMU1 are pulled high on pins 13 and 14 of the JTAG
connector.
> 2. You had also suggested that if the address 0 of DSP has 'garbage
> values', upon release, it might not give control to emulation logic
> and suggested that HPI be used for putting a 'endless loop' in
> address 0 of DSP. In my board design, I dont have any provision to
> do HPI booting.
You do not need a provision for HPI booting to use this technique -
you only need to be able to set the configuration so that the DSP
comes up in HPI boot mode - the DSP will set there doing nothing until
you connect the emulator. The idea is that you do this for initial
debug and then set it to ROM boot [I assume] when you get code in
flash.
> Moreover, I cannot put the 'endless loop' in ROM too
> since I can access ROM only by running a CCS program and burning hex
> data into the ROM. Hence I find myself in a deadlock situation now.
> Is there any other alternate way to make DSP come out of this state?
I hope that you can access the EMIF connections to temporarily tweak
the pullup/pulldowns [or FPGA] to adjust the boot mode.
Some board design thoughts [I realize that it is a little late for this]:
1. I like for boards to be configurable for more than 1 boot mode [you
can add a couple of pullup/pulldown resitor pads, jumpers, or jumpers
to an FPGA/CPLD that controls the boot modes].
2. For devices that support HOLD on the EMIF, you can add a provision
to assert HOLD. This tristates the EMIF - it can be used to identify
shorted traces or to provide a clever method to access a Flash device
externally.
Keep in mind that your problem coupld be something else. Check your
basics - power on reset, clock and power supplies. An erratic power
source that glitches or varies downward during power up can get the
DSP in a lockup or 'brain damaged state'. The only way that you will
catch this is to monitor the power on voltage ramp with a scope.
One troubleshooting technique is to take a couple of good boards and
check the state of everything that you can access and compare it to a
'bad board'.
Hopefully, this might get you started in the right direction.
Let us know your progress.
mikedunn
>
> Please let me know your suggestions.
>
> Thanks in advance,
> Kalaivani
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●March 17, 20082008-03-17
Kalaivani,
On 3/17/08, Adolf Klemenz wrote:
> Hi Kalaivani,
>
> these production programming problems are well-known to us too. I assume
> you have connected a Flash EPROM to EMIFA and configured the DM640 to EMIFA
> boot (address lines AEA[22:21] pulled up). If an empty Flash is attached,
> the DSP will read all FF's which result in invalid opcodes. The DSP crashes
> and emulator connection is not always possible. The same may happen in "no
> boot" configuration if the internal memory contains garbage.
>
> Since the DM640 can't be configured to HPI mode, the best option is
> producing the boards with pre-programmed Flash devices.
This is ideal. One option is to order Flash preprogrammed with
dianostics and rewrite the Flash in production [since production code
seems to always change].
> If this can't be
> done, you must power cycle the DSP board and retry to connect several
> times. From my experience this will succeed at least after ten or so
> attempts. Then immediately program the Flash memory with a known good program.
Mr. Klemenz reminded me of a technique that I haven't had to use for a
while. If you have a 'reset button', hold it down while opening CCS.
When the splash screen appears, release the button. This will
sometimes cut down the number of retries to get CCS to come up.
mikedunn
>
> Best Regards,
> Adolf Klemenz, D.SignT
> At 13:16 17.03.2008 +0000, Kalaivani.S wrote:
>
> >Hi Mike,
> >We are using DM640-based custom boards with XDS510 PP
> >Emulator. During production, some of our boards do not seem to
> >connect with CCS while some of them do. We have checked the hardware
> >connections and JTAG signals of these boards with those that are
> >working and they seem similar. We tested the boards using SDConfig
> >utility and it is able to detect scan path and is able to run
> >diagnostics.
> >I just went through some of your previous posts in this forum
> >in the past and tried out couple of your suggestions:
> >1. You had suggested using XDSProbe utility. I tried using it and
> >when I tried setting a physical address, it kept throwing
> >ERROR_CTL_PORT error. The subsequent commands also failed saying the
> >utlity aborted. The CCS setup was done properly and I verified it in
> >the ccBrd0.dat file. Please let me know some simple command line
> >utlities using which I can check the JTAG connection.
> >2. You had also suggested that if the address 0 of DSP has 'garbage
> >values', upon release, it might not give control to emulation logic
> >and suggested that HPI be used for putting a 'endless loop' in
> >address 0 of DSP. In my board design, I dont have any provision to
> >do HPI booting. Moreover, I cannot put the 'endless loop' in ROM too
> >since I can access ROM only by running a CCS program and burning hex
> >data into the ROM. Hence I find myself in a deadlock situation now.
> >Is there any other alternate way to make DSP come out of this state?
> >
> >Please let me know your suggestions.
> >
> >Thanks in advance,
> >Kalaivani
> >
> >
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 3/17/08, Adolf Klemenz wrote:
> Hi Kalaivani,
>
> these production programming problems are well-known to us too. I assume
> you have connected a Flash EPROM to EMIFA and configured the DM640 to EMIFA
> boot (address lines AEA[22:21] pulled up). If an empty Flash is attached,
> the DSP will read all FF's which result in invalid opcodes. The DSP crashes
> and emulator connection is not always possible. The same may happen in "no
> boot" configuration if the internal memory contains garbage.
>
> Since the DM640 can't be configured to HPI mode, the best option is
> producing the boards with pre-programmed Flash devices.
This is ideal. One option is to order Flash preprogrammed with
dianostics and rewrite the Flash in production [since production code
seems to always change].
> If this can't be
> done, you must power cycle the DSP board and retry to connect several
> times. From my experience this will succeed at least after ten or so
> attempts. Then immediately program the Flash memory with a known good program.
Mr. Klemenz reminded me of a technique that I haven't had to use for a
while. If you have a 'reset button', hold it down while opening CCS.
When the splash screen appears, release the button. This will
sometimes cut down the number of retries to get CCS to come up.
mikedunn
>
> Best Regards,
> Adolf Klemenz, D.SignT
> At 13:16 17.03.2008 +0000, Kalaivani.S wrote:
>
> >Hi Mike,
> >We are using DM640-based custom boards with XDS510 PP
> >Emulator. During production, some of our boards do not seem to
> >connect with CCS while some of them do. We have checked the hardware
> >connections and JTAG signals of these boards with those that are
> >working and they seem similar. We tested the boards using SDConfig
> >utility and it is able to detect scan path and is able to run
> >diagnostics.
> >I just went through some of your previous posts in this forum
> >in the past and tried out couple of your suggestions:
> >1. You had suggested using XDSProbe utility. I tried using it and
> >when I tried setting a physical address, it kept throwing
> >ERROR_CTL_PORT error. The subsequent commands also failed saying the
> >utlity aborted. The CCS setup was done properly and I verified it in
> >the ccBrd0.dat file. Please let me know some simple command line
> >utlities using which I can check the JTAG connection.
> >2. You had also suggested that if the address 0 of DSP has 'garbage
> >values', upon release, it might not give control to emulation logic
> >and suggested that HPI be used for putting a 'endless loop' in
> >address 0 of DSP. In my board design, I dont have any provision to
> >do HPI booting. Moreover, I cannot put the 'endless loop' in ROM too
> >since I can access ROM only by running a CCS program and burning hex
> >data into the ROM. Hence I find myself in a deadlock situation now.
> >Is there any other alternate way to make DSP come out of this state?
> >
> >Please let me know your suggestions.
> >
> >Thanks in advance,
> >Kalaivani
> >
> >
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●March 17, 20082008-03-17
Mike-
> On 3/17/08, Kalaivani.S wrote:
> > Hi Mike,
> > We are using DM640-based custom boards with XDS510 PP
> > Emulator. During production, some of our boards do not seem to
> > connect with CCS while some of them do. We have checked the hardware
> > connections and JTAG signals of these boards with those that are
> > working and they seem similar. We tested the boards using SDConfig
> > utility and it is able to detect scan path and is able to run
> > diagnostics.
> > I just went through some of your previous posts in this forum
> > in the past and tried out couple of your suggestions:
> > 1. You had suggested using XDSProbe utility. I tried using it and
> > when I tried setting a physical address, it kept throwing
> > ERROR_CTL_PORT error. The subsequent commands also failed saying the
> > utlity aborted. The CCS setup was done properly and I verified it in
> > the ccBrd0.dat file. Please let me know some simple command line
> > utlities using which I can check the JTAG connection.
> Unfortunately I do not believe that SD emulators can run xdsprobe [if
> they could, they would probably document it - I am not a user of SD
> emulators]. Since you seem to be addressing 'hard failures' and SD
> config passes, your JTAG path is likely to be okay. Just make sure
> that EMU0 and EMU1 are pulled high on pins 13 and 14 of the JTAG
> connector.
Mike I thought SD's XDS510 PP and USB emulators can run xdsprobe.exe... I thought I
recall doing that in our lab, but it's a been a while so now you got me wondering.
-Jeff
> On 3/17/08, Kalaivani.S wrote:
> > Hi Mike,
> > We are using DM640-based custom boards with XDS510 PP
> > Emulator. During production, some of our boards do not seem to
> > connect with CCS while some of them do. We have checked the hardware
> > connections and JTAG signals of these boards with those that are
> > working and they seem similar. We tested the boards using SDConfig
> > utility and it is able to detect scan path and is able to run
> > diagnostics.
> > I just went through some of your previous posts in this forum
> > in the past and tried out couple of your suggestions:
> > 1. You had suggested using XDSProbe utility. I tried using it and
> > when I tried setting a physical address, it kept throwing
> > ERROR_CTL_PORT error. The subsequent commands also failed saying the
> > utlity aborted. The CCS setup was done properly and I verified it in
> > the ccBrd0.dat file. Please let me know some simple command line
> > utlities using which I can check the JTAG connection.
> Unfortunately I do not believe that SD emulators can run xdsprobe [if
> they could, they would probably document it - I am not a user of SD
> emulators]. Since you seem to be addressing 'hard failures' and SD
> config passes, your JTAG path is likely to be okay. Just make sure
> that EMU0 and EMU1 are pulled high on pins 13 and 14 of the JTAG
> connector.
Mike I thought SD's XDS510 PP and USB emulators can run xdsprobe.exe... I thought I
recall doing that in our lab, but it's a been a while so now you got me wondering.
-Jeff
Reply by ●March 17, 20082008-03-17
Jeff,
On 3/17/08, Jeff Brower wrote:
> Mike-
>
> > On 3/17/08, Kalaivani.S wrote:
> > > Hi Mike,
> > > We are using DM640-based custom boards with XDS510 PP
> > > Emulator. During production, some of our boards do not seem to
> > > connect with CCS while some of them do. We have checked the hardware
> > > connections and JTAG signals of these boards with those that are
> > > working and they seem similar. We tested the boards using SDConfig
> > > utility and it is able to detect scan path and is able to run
> > > diagnostics.
> > > I just went through some of your previous posts in this forum
> > > in the past and tried out couple of your suggestions:
> > > 1. You had suggested using XDSProbe utility. I tried using it and
> > > when I tried setting a physical address, it kept throwing
> > > ERROR_CTL_PORT error. The subsequent commands also failed saying the
> > > utlity aborted. The CCS setup was done properly and I verified it in
> > > the ccBrd0.dat file. Please let me know some simple command line
> > > utlities using which I can check the JTAG connection.
>
> > Unfortunately I do not believe that SD emulators can run xdsprobe [if
> > they could, they would probably document it - I am not a user of SD
> > emulators]. Since you seem to be addressing 'hard failures' and SD
> > config passes, your JTAG path is likely to be okay. Just make sure
> > that EMU0 and EMU1 are pulled high on pins 13 and 14 of the JTAG
> > connector.
>
> Mike I thought SD's XDS510 PP and USB emulators can run xdsprobe.exe... I thought I
> recall doing that in our lab, but it's a been a while so now you got me wondering.
>
I can neither confirm or deny as I do not have an SD emulator. I would
be interested if anyone has done it.
I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
emulators as well as a few custom boards that had on board emulation.
The reason that I question it is that xdsprobe.exe 'sits on top of'
TI's xdsfast3.dll [scan manager] which SD does not use - they have a
proprietary scan manager and scan controller. It would be possible for
them to have an adapter DLL, but if they do, I am not aware of it [of
course there are many things of which I am not aware].
mikedunn
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
On 3/17/08, Jeff Brower wrote:
> Mike-
>
> > On 3/17/08, Kalaivani.S wrote:
> > > Hi Mike,
> > > We are using DM640-based custom boards with XDS510 PP
> > > Emulator. During production, some of our boards do not seem to
> > > connect with CCS while some of them do. We have checked the hardware
> > > connections and JTAG signals of these boards with those that are
> > > working and they seem similar. We tested the boards using SDConfig
> > > utility and it is able to detect scan path and is able to run
> > > diagnostics.
> > > I just went through some of your previous posts in this forum
> > > in the past and tried out couple of your suggestions:
> > > 1. You had suggested using XDSProbe utility. I tried using it and
> > > when I tried setting a physical address, it kept throwing
> > > ERROR_CTL_PORT error. The subsequent commands also failed saying the
> > > utlity aborted. The CCS setup was done properly and I verified it in
> > > the ccBrd0.dat file. Please let me know some simple command line
> > > utlities using which I can check the JTAG connection.
>
> > Unfortunately I do not believe that SD emulators can run xdsprobe [if
> > they could, they would probably document it - I am not a user of SD
> > emulators]. Since you seem to be addressing 'hard failures' and SD
> > config passes, your JTAG path is likely to be okay. Just make sure
> > that EMU0 and EMU1 are pulled high on pins 13 and 14 of the JTAG
> > connector.
>
> Mike I thought SD's XDS510 PP and USB emulators can run xdsprobe.exe... I thought I
> recall doing that in our lab, but it's a been a while so now you got me wondering.
>
I can neither confirm or deny as I do not have an SD emulator. I would
be interested if anyone has done it.
I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
emulators as well as a few custom boards that had on board emulation.
The reason that I question it is that xdsprobe.exe 'sits on top of'
TI's xdsfast3.dll [scan manager] which SD does not use - they have a
proprietary scan manager and scan controller. It would be possible for
them to have an adapter DLL, but if they do, I am not aware of it [of
course there are many things of which I am not aware].
mikedunn
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467
Reply by ●March 17, 20082008-03-17
Jeff,
On 3/17/08, Jeff Brower wrote:
> Mike-
>
> > I can neither confirm or deny as I do not have an SD emulator. I would
> > be interested if anyone has done it.
> >
> > I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
> > emulators as well as a few custom boards that had on board emulation.
> > The reason that I question it is that xdsprobe.exe 'sits on top of'
> > TI's xdsfast3.dll [scan manager] which SD does not use - they have a
> > proprietary scan manager and scan controller. It would be possible for
> > them to have an adapter DLL, but if they do, I am not aware of it [of
> > course there are many things of which I am not aware].
>
> I think SD's proprietary scan manager is due to their chunk of obfuscation circuitry
> on their DSK boards. If the target is a non-SD / user-defined board, then I suspect
> that TI's scan manager would work, as the "black circuit" thing would be independent
> of the JTAG emulator itself.
Not exactly.
The scan manger software contains I/O reads and writes to the JTAG
serializer/deserializer chip. The original PP used the same chip
[SN74ACT8990] as the TI XDS510 and 6211 DS [an ancient 5v part]. SD
designed their own serializer/deserializer and put it into a
programmable device. It is totally different than anything that TI
offers.
SD also runs some or all of their scan manager software on the USB
chip on the DSK [or emulator pod] to improve performance.
mikedunn
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 3/17/08, Jeff Brower wrote:
> Mike-
>
> > I can neither confirm or deny as I do not have an SD emulator. I would
> > be interested if anyone has done it.
> >
> > I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
> > emulators as well as a few custom boards that had on board emulation.
> > The reason that I question it is that xdsprobe.exe 'sits on top of'
> > TI's xdsfast3.dll [scan manager] which SD does not use - they have a
> > proprietary scan manager and scan controller. It would be possible for
> > them to have an adapter DLL, but if they do, I am not aware of it [of
> > course there are many things of which I am not aware].
>
> I think SD's proprietary scan manager is due to their chunk of obfuscation circuitry
> on their DSK boards. If the target is a non-SD / user-defined board, then I suspect
> that TI's scan manager would work, as the "black circuit" thing would be independent
> of the JTAG emulator itself.
Not exactly.
The scan manger software contains I/O reads and writes to the JTAG
serializer/deserializer chip. The original PP used the same chip
[SN74ACT8990] as the TI XDS510 and 6211 DS [an ancient 5v part]. SD
designed their own serializer/deserializer and put it into a
programmable device. It is totally different than anything that TI
offers.
SD also runs some or all of their scan manager software on the USB
chip on the DSK [or emulator pod] to improve performance.
mikedunn
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●March 17, 20082008-03-17
Mike-
> I can neither confirm or deny as I do not have an SD emulator. I would
> be interested if anyone has done it.
>
> I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
> emulators as well as a few custom boards that had on board emulation.
> The reason that I question it is that xdsprobe.exe 'sits on top of'
> TI's xdsfast3.dll [scan manager] which SD does not use - they have a
> proprietary scan manager and scan controller. It would be possible for
> them to have an adapter DLL, but if they do, I am not aware of it [of
> course there are many things of which I am not aware].
I think SD's proprietary scan manager is due to their chunk of obfuscation circuitry
on their DSK boards. If the target is a non-SD / user-defined board, then I suspect
that TI's scan manager would work, as the "black circuit" thing would be independent
of the JTAG emulator itself.
-Jeff
> I can neither confirm or deny as I do not have an SD emulator. I would
> be interested if anyone has done it.
>
> I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
> emulators as well as a few custom boards that had on board emulation.
> The reason that I question it is that xdsprobe.exe 'sits on top of'
> TI's xdsfast3.dll [scan manager] which SD does not use - they have a
> proprietary scan manager and scan controller. It would be possible for
> them to have an adapter DLL, but if they do, I am not aware of it [of
> course there are many things of which I am not aware].
I think SD's proprietary scan manager is due to their chunk of obfuscation circuitry
on their DSK boards. If the target is a non-SD / user-defined board, then I suspect
that TI's scan manager would work, as the "black circuit" thing would be independent
of the JTAG emulator itself.
-Jeff
Reply by ●March 17, 20082008-03-17
Mike-
> On 3/17/08, Jeff Brower wrote:
> > Mike-
> >
> > > I can neither confirm or deny as I do not have an SD emulator. I would
> > > be interested if anyone has done it.
> > >
> > > I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
> > > emulators as well as a few custom boards that had on board emulation.
> > > The reason that I question it is that xdsprobe.exe 'sits on top of'
> > > TI's xdsfast3.dll [scan manager] which SD does not use - they have a
> > > proprietary scan manager and scan controller. It would be possible for
> > > them to have an adapter DLL, but if they do, I am not aware of it [of
> > > course there are many things of which I am not aware].
> >
> > I think SD's proprietary scan manager is due to their chunk of obfuscation circuitry
> > on their DSK boards. If the target is a non-SD / user-defined board, then I suspect
> > that TI's scan manager would work, as the "black circuit" thing would be independent
> > of the JTAG emulator itself.
>
> Not exactly.
>
> The scan manger software contains I/O reads and writes to the JTAG
> serializer/deserializer chip. The original PP used the same chip
> [SN74ACT8990] as the TI XDS510 and 6211 DS [an ancient 5v part].
The SD XDS510PP emulators we have in the lab contain the Actel PLD. When I get a
chance I will try xdsprobe. The OP's problem might have been that he was using
Vista, not WinXP, causing the I/O error message.
SD does seem to imply on this page () that xdsprobe.exe will work:
http://support.spectrumdigital.com/ccs3x_xds560r/Release-30x20/sd_xds560r_releasenotes.html
or at least they don't say it won't work with their products.
> SD
> designed their own serializer/deserializer and put it into a
> programmable device. It is totally different than anything that TI
> offers.
My understanding is it's not that different -- they repeated the necessary
functionality but used the Actel device for security fuse reasons, otherwise they
would use the TI device (as do SEED and other emulator mfgs). SD is mandated to use
TI parts whenever possible; for them to use something different requires a special
reason and my understanding is it's the whole thing about obfuscation circuitry, both
in the emulator pod and on the DSK board (which has another Actel PLD).
> SD also runs some or all of their scan manager software on the USB
> chip on the DSK [or emulator pod] to improve performance.
There is not a "USB chip" on the SD DSK boards; the actual USB interface is the
'other' DSP on the DSK boards, typically a 320DA250 audio DSP device that doesn't
appear in the schematics. If SD runs software on the DSK outside of the DSP it has
to be in this non-documented circuitry (which includes another Actel PLD with
security fuse activated).
-Jeff
> On 3/17/08, Jeff Brower wrote:
> > Mike-
> >
> > > I can neither confirm or deny as I do not have an SD emulator. I would
> > > be interested if anyone has done it.
> > >
> > > I have used xdsprobe on TI, BlackHawk, Kane, Softronix, WinTech
> > > emulators as well as a few custom boards that had on board emulation.
> > > The reason that I question it is that xdsprobe.exe 'sits on top of'
> > > TI's xdsfast3.dll [scan manager] which SD does not use - they have a
> > > proprietary scan manager and scan controller. It would be possible for
> > > them to have an adapter DLL, but if they do, I am not aware of it [of
> > > course there are many things of which I am not aware].
> >
> > I think SD's proprietary scan manager is due to their chunk of obfuscation circuitry
> > on their DSK boards. If the target is a non-SD / user-defined board, then I suspect
> > that TI's scan manager would work, as the "black circuit" thing would be independent
> > of the JTAG emulator itself.
>
> Not exactly.
>
> The scan manger software contains I/O reads and writes to the JTAG
> serializer/deserializer chip. The original PP used the same chip
> [SN74ACT8990] as the TI XDS510 and 6211 DS [an ancient 5v part].
The SD XDS510PP emulators we have in the lab contain the Actel PLD. When I get a
chance I will try xdsprobe. The OP's problem might have been that he was using
Vista, not WinXP, causing the I/O error message.
SD does seem to imply on this page () that xdsprobe.exe will work:
http://support.spectrumdigital.com/ccs3x_xds560r/Release-30x20/sd_xds560r_releasenotes.html
or at least they don't say it won't work with their products.
> SD
> designed their own serializer/deserializer and put it into a
> programmable device. It is totally different than anything that TI
> offers.
My understanding is it's not that different -- they repeated the necessary
functionality but used the Actel device for security fuse reasons, otherwise they
would use the TI device (as do SEED and other emulator mfgs). SD is mandated to use
TI parts whenever possible; for them to use something different requires a special
reason and my understanding is it's the whole thing about obfuscation circuitry, both
in the emulator pod and on the DSK board (which has another Actel PLD).
> SD also runs some or all of their scan manager software on the USB
> chip on the DSK [or emulator pod] to improve performance.
There is not a "USB chip" on the SD DSK boards; the actual USB interface is the
'other' DSP on the DSK boards, typically a 320DA250 audio DSP device that doesn't
appear in the schematics. If SD runs software on the DSK outside of the DSP it has
to be in this non-documented circuitry (which includes another Actel PLD with
security fuse activated).
-Jeff
Reply by ●March 17, 20082008-03-17
Mike-
> > SD does seem to imply on this page () that xdsprobe.exe will work:
> >
> >
> > http://support.spectrumdigital.com/ccs3x_xds560r/Release-30x20/sd_xds560r_releasenotes.html
> >
> > or at least they don't say it won't work with their products.
>
> XDS560 emulators are a totally different animal. They have a
> different license than XDS510 class emulators [presumably as a result
> of 'lessoned learned' from the XDS510].
> As I understand it, all XDS560 emulators will [or should]:
> 1. run xdsprobe.exe.
> 2. run TI XDS560 drivers.
> 3. contain a core TI provided architecture.
> 4. support a variable TCLK rate.
> Vendor differentiation is provided via connectivity, processor speed,
> memory size/speed, etc. [according to what I remember from the TI
> 'commercial'].
Hmm, it sounds to me like TI has put their foot down. Emulator vendors will be
assimilated, resistance is futile.
> > There is not a "USB chip" on the SD DSK boards; the actual USB interface is the
> > 'other' DSP on the DSK boards, typically a 320DA250 audio DSP device that doesn't
> > appear in the schematics. If SD runs software on the DSK outside of the DSP it has
> > to be in this non-documented circuitry (which includes another Actel PLD with
> > security fuse activated).
>
> That is exactly what I am referring to - they run some scan control sw
> on the 'USB DSP chip' to reduce the number of USB transactions.
Ok got ya. That sounds good and if performance is improved then it's truly good, but
my conclusion is the main purpose of Spectrum Digital's "black circuitry" is to make
it difficult to reverse engineer DSK boards that are CCS compatible; i.e. work with
CCS + USB and no emulator.
-Jeff
> > SD does seem to imply on this page () that xdsprobe.exe will work:
> >
> >
> > http://support.spectrumdigital.com/ccs3x_xds560r/Release-30x20/sd_xds560r_releasenotes.html
> >
> > or at least they don't say it won't work with their products.
>
> XDS560 emulators are a totally different animal. They have a
> different license than XDS510 class emulators [presumably as a result
> of 'lessoned learned' from the XDS510].
> As I understand it, all XDS560 emulators will [or should]:
> 1. run xdsprobe.exe.
> 2. run TI XDS560 drivers.
> 3. contain a core TI provided architecture.
> 4. support a variable TCLK rate.
> Vendor differentiation is provided via connectivity, processor speed,
> memory size/speed, etc. [according to what I remember from the TI
> 'commercial'].
Hmm, it sounds to me like TI has put their foot down. Emulator vendors will be
assimilated, resistance is futile.
> > There is not a "USB chip" on the SD DSK boards; the actual USB interface is the
> > 'other' DSP on the DSK boards, typically a 320DA250 audio DSP device that doesn't
> > appear in the schematics. If SD runs software on the DSK outside of the DSP it has
> > to be in this non-documented circuitry (which includes another Actel PLD with
> > security fuse activated).
>
> That is exactly what I am referring to - they run some scan control sw
> on the 'USB DSP chip' to reduce the number of USB transactions.
Ok got ya. That sounds good and if performance is improved then it's truly good, but
my conclusion is the main purpose of Spectrum Digital's "black circuitry" is to make
it difficult to reverse engineer DSK boards that are CCS compatible; i.e. work with
CCS + USB and no emulator.
-Jeff
