That's some pretty strong evidence that the JTAG state machine is susceptible to
undefined op codes -- maybe that situation is harder to deal with for a VLIW
Another possibility is that the code appears to act normally, but jumps to
zero (Reset vector) every now and then due to null pointer or other reason. In
case, the the chip does a Reset and the code starts over. That would stop -- or
confuse -- JTAG but the program might still appear to be Ok, depending on what
-Jeff -------- Original Message --------
Subject: Re: [Fwd: Re: [c6x] can't connect to target after flashburn]
Date: Sun, 7 Mar 2004 21:57:19 -0800 (PST)
From: Mike Dunn <>
To: Jeff Brower <>
Hello Jeff, I agree with you - if all is well. it is true, JTAG is enabled -
is a long journey for the JTAG signals to traverse from the JTAG clock domain to
from the CPU. There are certain synchronizations and timing windows that must
for emulation transactions to succeed [like halting the DSP for one]. I do not
for sure the exact cause and I have only known this situation to occur when the
was executing something other than legal code. I speculate that one possible
is a memory cycle starts but never ends - this would lock out emulation control
the cycle completes. My most recent empirical evidence comes from the 6711 DSK.
jumpered it to change the endianness and I could not get emulation control 90%
percent of the time [since BE mode was 'booting' from the high byte of the data
the DSP was eating garbage...]. I have also had similar experiences with
flash". I think the root of the problem has to do with "executing garbage" and
instruction set that is not fully decoded.regards,mikedunn
Jeff Brower <> wrote:
What can programming Flash do to hold up JTAG on the DSK board? It must be
specific, because normally -- as long as C67xx reset is not held and JTAG
still connected and healthy - JTAG should be enabled. I suppose the CCS
doing something else it needs to initialize, not just JTAG, and the program
from Flash has somehow got in the way.
-------- Original Message --------
Subject: Re: [c6x] can't connect to target after flashburn
Date: Wed, 3 Mar 2004 21:34:50 -0800 (PST)
From: Mike Dunn
To: stino_rides ,
Hello Stijn, It is possible for the programmation of the FLASH to prevent
emulator from taking control. One way to get around the problem is to bring
board in HPI boot mode. After reset the DSP wil l "hang", until the
up. The only trick is to "get there"... Since I do not know your
situation, I will provide a couple of suggestions. [Refer to the DSK
5, to see what is going on] IF YOU DO NOT UNDERSTAND ANY OF THE FOLLOWING,
OR GET HELP! 1. Use a fine "clip lead" to connect U20 pin 5 [a convenient,
marked, corner pin] to ground [the JTAG connector pin 4 is easy]. you can
connected as long as you need it. 2. solder a very short piece of wire in
position - this will cause HPI boot to be permanent. 3. [my favorite] Run a
small gauge wire from "the R82 pad that connects to R83" to "the switched
unused switch #4" [I think that it is the one near the board edge]. Use sw
enable/disable HPI boot mode.Happy "booting",mikedunn
I encountered a pretty severe problem today: i wanted to test the
flashb urn program, I did this by burning the supplied FlashBlink
The burned program does start without any problems, but now I cannot
connect to the c6711dsk anymore. ('Can't initialize target cpu etc.).
I tried everything (reset, power on/off) but it does not work..
I did not find any jumpers or so to disable booting from flash,
anyone knows what I can do?
[Fwd: Re: [Fwd: Re: can't connect to target after flashburn]]
The problem [c6x specificly] does not have to do with JTAG opcodes, it is with CPU instructions. This is my take on what is happening... I know that you are aware of some of this, but i can't start in the middle.
The JTAG state machine and some related logic operate in what I will call the "JTAG Clock Domain" [TCLK].
The CPU and related logic operate in the "CPU clock domain". There is synchronization logic between the two.
For the emulator to gain control of a 62xx/67xx device, a command must be scanned in via JTAG to halt the device. For this command to take effect in the CPU domain there must be a "window of opportunity" present [I surmise that this window of opportunity normally occurs between CPU instructions].
<<I digress for a war story>>
I have had a very memorable 6201 experience where a CPLD [that was incorrectly programmed] would present "not ready yet" in an async memory cycle that would totally 'lock out' all emulation accesses. Some experimentation indicated that JTAG control was not possible while ready was hung false.
<<end of war story>>
This experience and some others relating to the "execution of garbage" seem to confirm my suspicions.
I am sure others are bored with this...
Jeff Brower <j...@signalogic.com> wrote: