Forums

[Fwd: Re: [Fwd: Re: can't connect to target after flashburn]]

Started by Jeff Brower March 8, 2004
Mike-

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

Another possibility is that the code appears to act normally, but jumps to
location
zero (Reset vector) every now and then due to null pointer or other reason. In
that
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
it was
doing.

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

Hello Jeff, I agree with you - if all is well. it is true, JTAG is enabled -
but it
is a long journey for the JTAG signals to traverse from the JTAG clock domain to
and
from the CPU. There are certain synchronizations and timing windows that must
occur
for emulation transactions to succeed [like halting the DSP for one]. I do not
know
for sure the exact cause and I have only known this situation to occur when the
DSP
was executing something other than legal code. I speculate that one possible
cause
is a memory cycle starts but never ends - this would lock out emulation control
until
the cycle completes. My most recent empirical evidence comes from the 6711 DSK.
I
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
bus
the DSP was eating garbage...]. I have also had similar experiences with
"trashed
flash". I think the root of the problem has to do with "executing garbage" and
an
instruction set that is not fully decoded.regards,mikedunn
Jeff Brower <> wrote:

Mike-

What can programming Flash do to hold up JTAG on the DSK board? It must be
DSK board
specific, because normally -- as long as C67xx reset is not held and JTAG
signals are
still connected and healthy - JTAG should be enabled. I suppose the CCS
driver is
doing something else it needs to initialize, not just JTAG, and the program
running
from Flash has somehow got in the way.

-Jeff

-------- 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
the
emulator from taking control. One way to get around the problem is to bring
up the
board in HPI boot mode. After reset the DSP wil l "hang", until the
emulator comes
up. The only trick is to "get there"... Since I do not know your
capabilities or
situation, I will provide a couple of suggestions. [Refer to the DSK
schematics, page
5, to see what is going on] IF YOU DO NOT UNDERSTAND ANY OF THE FOLLOWING,
IGNORE IT
OR GET HELP! 1. Use a fine "clip lead" to connect U20 pin 5 [a convenient,
and
marked, corner pin] to ground [the JTAG connector pin 4 is easy]. you can
leave this
connected as long as you need it. 2. solder a very short piece of wire in
the R82
position - this will cause HPI boot to be permanent. 3. [my favorite] Run a
piece of
small gauge wire from "the R82 pad that connects to R83" to "the switched
pin of
unused switch #4" [I think that it is the one near the board edge]. Use sw
4 to
enable/disable HPI boot mode.Happy "booting",mikedunn
stino_rides wrote:

Hi
I encountered a pretty severe problem today: i wanted to test the
flashb urn program, I did this by burning the supplied FlashBlink
example,
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?
Thanks,
Stijn



Jeff,
 
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...
 
mikedunn

Jeff Brower <j...@signalogic.com> wrote:
Mike-

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

Another possibility is that the code appears to act normally, but jumps to location
zero (Reset vector) every now and then due to null pointer or other reason. In that
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 it was
doing.

-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
CC: c...@yahoogroups.com

Hello Jeff, I agree with you - if all is well. it is true, JTAG is enabled - but it
is a long journey for the JTAG signals to traverse from the JTAG clock domain to and
from the CPU. There are certain synchronizations and timing windows that must occur
for emulation transactions to succeed [like halting the DSP for one]. I do not know
for sure the exact cause and I have only known this situation to occur when the DSP
was executing something other than legal code. I speculate that one possible cause
is a memory cycle starts but never ends - this would lock out emulation control until
the cycle completes. My most recent empirical evidence comes from the 6711 DSK. I
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 bus
the DSP was eating garbage...]. I have also had similar experiences with "trashed
flash". I think the root of the problem has to do with "executing garbage" and an
instruction set that is not fully decoded.regards,mikedunn
Jeff Brower wrote:

Mike-

What can programming Flash do to hold up JTAG on the DSK board? It must be
DSK board
specific, because normally -- as long as C67xx reset is not held and JTAG
signals are
still connected and healthy - JTAG should be enabled. I suppose the CCS
driver is
doing something else it needs to initialize, not just JTAG, and the program
running
from Flash has somehow got in the way.

-Jeff

-------- 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 , c...@yahoogroups.com

Hello Stijn, It is possible for the programmation of the FLASH to prevent
the
emulator from taking control. One way to get around the problem is to bring
up the
board in HPI boot mode. After reset the DSP wil l "hang", until the
emulator comes
up. The only trick is to "get there"... Since I do not know your
capabilities or
situation, I will provide a couple of suggestions. [Refer to the DSK
schematics, page
5, to see what is going on] IF YOU DO NOT UNDERSTAND ANY OF THE FOLLOWING,
IGNORE IT
OR GET HELP! 1. Use a fine "clip lead" to connect U20 pin 5 [a convenient,
and
marked, corner pin] to ground [the JTAG connector pin 4 is easy]. you can
leave this
connected as long as you need it. 2. solder a very short piece of wire in
the R82
position - this will cause HPI boot to be permanent. 3. [my favorite] Run a
piece of
small gauge wire from "the R82 pad that connects to R83" to "the switched
pin of
unused switch #4" [I think that it is the one near the board edge]. Use sw
4 to
enable/disable HPI boot mode.Happy "booting",mikedunn
stino_rides wrote:

Hi
I encountered a pretty severe problem today: i wanted to test the
flashb urn program, I did this by burning the supplied FlashBlink
example,
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?
Thanks,
Stijn

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join: Send an email to c...@yahoogroups.com

To Post: Send an email to c...@yahoogroups.com

To Leave: Send an email to c...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/c6x

Other Groups: http://www.dsprelated.com

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/c6x/

<*> To unsubscribe from this group, send an email to:
c...@yahoogroups.com

<*>