56800/E USB TAP debugging on a JTAG chain

[JimmyMood]

I have submitted this question to Freescale support and they have ignored me for an entire week and now I understand why they have no telephone support.  I suppose if they don't know, no one else here will but I'm getting desperate. 

How do you configure the debugger to work on a JTAG chain with other devices in the chain?  In the project settings, in the debugger->remote debugging panel, click on Edit Connection (with USB TAP selected)  A dialog appears with a "Multi-core debugging" checkbox and a "JTAG configuration" file edit box. 

What is the file format for the JTAG configuration file?  It would be awesome if the wrote that down in the User Guide somewhere, but hell if I can find it.  Anyone know the answer? Buler? Buler?

[JimmyMood]

Is there any resolution to this yet?  Why can't I get tech support on the phone, via e-mail, or even on this forum? 

[Alban]

Hi Jimmy,

Please read the Private Message I sent you, for the matter to be investigated.

You should be receiving Technical Support through the phone and via email through the Technical Information Centre (via Service Requests), like you did.

However, you don't necessarily get resolution of all problems on the Forums.

Alban.

[Alban]

Dear All,

I have been following up on this issue with experts offline.

The investigation is still in progress in order to find a suitable solution.

From what I understood it is not individual points which are not possible but the special combination Jimmy is using that is causing trouble: USBTAP and JTAG chain.

Cheers,

Alban.

[kenc]

I'm not sure if multi-device chains are tested or fully supported by the 56800 tools, but copied below an example JTAG configuration file for Starcore.  I think you can use DSP568 instead of SC140.

Ken

#  
# Standards for this file
# 1. Comments begin with the character '#'.
# 2.  A StarCore device is specified with:
#   SC140
# 3. A non-StarCore device is specified with:
#   Generic <Value_1> <Value_2> <Value_3>
#  Value_1 is the length in bits of the JTAG instruction register.
#  Value_2 is the length in bits of the JTAG bypass register.
#  Value_3 is the hex value of the JTAG bypass instruction.
#  Hex values are prefixed with 0x.
# 4. Each device is specified on a new line.
# 5. Device specification is case sensitive, and a Generic device
#  cannot be specifed without all three values.
#
# An example configuration is shown below:

SC140
Generic 4 1 0xf

[rocco]

---

kenc wrote:
I'm not sure if multi-device chains are tested or fully supported by the 56800 tools . . .

---

What about a DSP56303?

I recently sent to fab a board with a DSP56303 in front of an FPGA in a JTAG chain. I found nothing in the documentation that said I shouldn't do this. Will I not be able to debug?

[tedw]

---

rocco wrote:
I recently sent to fab a board with a DSP56303 in front of an FPGA in a JTAG chain. I found nothing in the documentation that said I shouldn't do this. Will I not be able to debug?

---

The current Suite56 tools do not implement generic devices. If your FPGA has an IR length of 4 and uses 0x8 as the BYPASS command, you might be able to tell the debugger that it is a 56300 device. If this isn't the case, you almost certainly won't be able to use the debugger in this situation.

[JimmyMood]

I've been struggling to get the USB TAP to work at all, and finally thank goodness it works on my evaluation board.

I'm a bit shocked by some of the statements made on this thread.  I assumed JTAG and Chains go hand-in-hand. I am using an 56F8322 on a target board with 4 other devices in the JTAG chain.  This has not been a problem for the vendors of the other 4 parts.

Some concise questions:

Kenc: What is HawkV1 and HawkV2?  How do I know if my 56F322 has this flaw?

tedw: What do you mean "Won't support generic devices"?  Is my config file below invalid? 

By the IEEE JTAG 1149.1, the bypass instruction HAS to be filling the instruction register with 1's.  Why do you say the bypass instruction for your device is 0x8 and not 0xF?

Code:

#control board JTAG initialization file for Metroworks Code Warrior#8051F120Generic 16 1 0xFFFF#EPLD1Generic 10 1 0x3FF#EPLD2Generic 10 1 0x3FF#EPLD3Generic 10 1 0x3FF#DSPDSP56800

When I attempt to load this file for mult-core debugging, I get no confirmation that it was parsed correctly.  If I exit out of the dialog where the file is selected, then re-enter the dialog, the checkbox for multi-core debuggin is unchecked.  I assume this means the jtag configuration file did not take.  How do I get this to work?

I need the following from my JTAG tools for the 56F8322:

• Program the device in a chain
• Debugging of the device in a chain

Will USB TAP support these functions?  If USB TAP does not, what 3rd party tools will?

Regards,

-Jim
 

Message Edited by JimmyMood on 2006-08-23 04:45 PM

[rocco]

Hi, Ken and Ted:

To try to gleam some insight on Jim's questions, I just spent 2 hours scouring the Freescale website, and did not find relief. Here is what I need to know (in addition to Jim, whose thread I seem to be hijacking):

Are the HawkV1 and HawkV2 two classes of 56f DSCs? with the 56Fxxx being HawkV1 and the 56Fxxxx being HawkV2? (the V2 means an extra digit in the part number?)

It appears that only StarCore has EonCE, rather then OnCE. Is this true?

How does that relate to DSP56303? Does it have the silicon flaw?

Are you saying that my run of PCBs is scrap, because I put an FPGA in the same chain as the DSP56303?

If a Freescale DSP can't be in a chain with other devices, how do they get across the production/test floor?

Where are these limitations documented? (I've checked all the errata I could find).

[kenc]

I asked around a bit and the only restriction on multi-device chains I could find was this:

"Note: This cannot be done with current HawkV2 devices due to a design flaw in the EOnCE. Some future device will address this problem.  This was a silicon bug with all 5683xx and 5685x processors. Freescale addressed this in the new line of processors 56801x (Anguilla faily). It should work with verison 7.2 for these new devices.  This was not a problem with Hawk v1."

Ken