JTAG issues.. Please help Mike

Jeff,

On 3/17/08, Jeff Brower wrote:
> 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.

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'].

There are almost no ground rules for XDS510 class emulators.

>
> > 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).
>
The JTAG controller is essentially a 'serial port with a little extra
logic'. All vendor's JTAG controllers have similar base
functionality, but the programming models can vary significantly.

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

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.

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

Hi all,
Thanks for your suggestions. We are still debugging the issue. We tried programming the Flash on a working board with a small code to continuously blink an LED on boot-up. We then soldered the programmed Flash chip on the non-functional board and tried booting that board up without any success. We checked the clock, Power, Reset, etc.. everything seems fine. We again tried connecting using XDS510 emulator. Sometimes it is able to connect but if we power off and reboot, it is not able to connect.

Mike,
I tried putting a endless loop in Flash and tried booting up in ROM-boot mode and then connecting using the emulator. The board was not able to connect. Further, DM640 cannot support HPI boot mode.

Please let me know if you have any suggestions.

Thanks,
Kalaivani.S

----- Original Message ----
From: Michael Dunn
To: Jeff Brower
Cc: c...
Sent: Monday, March 17, 2008 10:10:22 PM
Subject: Re: [c6x] JTAG issues.. Please help Mike

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

Kalai-

> Thanks for your suggestions. We are still debugging the issue. We
> tried programming the Flash on a working board with a small code to
> continuously blink an LED on boot-up. We then soldered the programmed
> Flash chip on the non-functional board and tried booting that board up
> without any success. We checked the clock, Power, Reset, etc..
> everything seems fine. We again tried connecting using XDS510 emulator.
> Sometimes it is able to connect but if we power off and reboot, it is
> not able to connect.
>
> Mike,
> I tried putting a endless loop in Flash and tried booting up in
> ROM-boot mode and then connecting using the emulator. The board was
> not able to connect. Further, DM640 cannot support HPI boot mode.
>
> Please let me know if you have any suggestions.

You have to verify the loop in your boot code is running before you can connect.
Your idea about blinking an LED inside the loop is a good one. As long as you see
the LED blinking after boot, you should be able to connect with the emulator.

As far as what's wrong with your non-working board, it's hard to say. You've checked
the basics... did you check one of the CLKOUT signals, to make sure the PLL has a
legal value? You checked power, but did you check quality of the power levels?
Ripple is within spec? Is there a Vcc-PLL input on the DM640? What about JTAG mode
signals like EMU0, EMU1, initial value of /TRST, etc. You should compare those
carefully vs. the working board.

-Jeff

> ----- Original Message ----
> From: Michael Dunn
> To: Jeff Brower
> Cc: c...
> Sent: Monday, March 17, 2008 10:10:22 PM
> Subject: Re: [c6x] JTAG issues.. Please help Mike
>
> 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/deserial izer 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/deserial izer 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
>
>
> Start a New Thread

Hi all,
Thanks for all your inputs. We finally traced the problem. Some of the boards had the oscillator which provides DSP_CLKIN improperly oriented. We corrected them and we were able to get the emulator connect to CCS. We realized that the CLKIN was not proper only after we probed the DSP CLKIN pin directly. Earlier we probed at a different location and misconstrued that clock was fine.
But this has left us with a really puzzling problem. With the oscillator wrongly oriented, the DSP_CLKIN pin remains high always. And some of our boards work PERFECTLY fine even with this anomaly. Can anybody throw light upon this issue? It completely baffles me why this would happen.

Thanks,
Kalaivani.S

----- Original Message ----
From: Jeff Brower
To: Michael Dunn
Cc: c...
Sent: Tuesday, March 18, 2008 3:01:27 AM
Subject: Re: [c6x] JTAG issues.. Please help Mike

Mike-

> > SD does seem to imply on this page () that xdsprobe.exe will work:
> >
> >
> > http://support. spectrumdigital. com/ccs3x_ xds560r/Release- 30x20/sd_ xds560r_releasen otes.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 Start a New Thread

Kalaivani,

On 4/9/08, kalai vani wrote:
>
> Hi all,
>
> Thanks for all your inputs. We finally traced the problem. Some of the
> boards had the oscillator which provides DSP_CLKIN improperly oriented. We
> corrected them and we were able to get the emulator connect to CCS. We
> realized that the CLKIN was not proper only after we probed the DSP CLKIN
> pin directly. Earlier we probed at a different location and misconstrued
> that clock was fine.
>

Thanks for the feedback, Kalaivani.
Note to all:
When new boards do not work, revert to basics. Numerous complex problems are
resolved by checking voltages, grounds, and clocks carefully. I suggest
doing this with ANY symptom on a newly designed or manufactured board.

But this has left us with a really puzzling problem. With the
> oscillator wrongly oriented, the DSP_CLKIN pin remains high always. And some
> of our boards work PERFECTLY fine even with this anomaly.
>
Does this mean that they ran at the correct frequency or that they 'passed
the tests'??
Can anybody throw light upon this issue? It completely baffles me why this
> would happen.
>
I don't remember what device that you are using, but I assure you that the
DSP will not run without a clock. Depending on the contruction of the
oscilator, you may not have had a 'true, driven high'. The output could have
been 'high impedance noise' [similar to a crystal] that was enough to
trigger the clk in logic but 'went away' when the load of a probe was
applied to the signal [if this was the case, the DSP would stop running when
the clk was probed]

mikedunn

>
> Thanks,
>
> Kalaivani.S
> ----- Original Message ----
> From: Jeff Brower
> To: Michael Dunn
> Cc: c...
> Sent: Tuesday, March 18, 2008 3:01:27 AM
> Subject: Re: [c6x] JTAG issues.. Please help Mike
>
> Mike-
>
> > > SD does seem to imply on this page () that xdsprobe.exe will work:
> > >
> > >
> > > http://support. spectrumdigital. com/ccs3x_ xds560r/Release- 30x20/sd_
> xds560r_releasen otes.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
> __________________________________________________

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread