|
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 |
|
|
[Fwd: Re: [Fwd: Re: can't connect to target after flashburn]]
Started by ●March 8, 2004
Reply by ●March 10, 20042004-03-10
|
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- |
