• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 402 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDSEMU110-U: Converting 2-wire cJTAG to 4/5-wire JTAG

Andrew Hana
Prodigy 40 points
Part Number: TMDSEMU110-U
Other Parts Discussed in Thread: SEGGER

I am a digital chip designer and we are embedding an MCU into our next chip.

The MCU core (embedded into the chip) has a 5-wire JTAG port for debug purposes.

We don’t really have 4 or 5 pins on the chip we can use for JTAG … so we would like to explore the cJTAG option instead.

I understand that that XDS110 supports both 5-wire JTAG and the 2-wire cJTAG protocols.

I have done some research on the cJTAG protocol and I am left with two conflicting impressions:

  • It is very simple to convert an incoming 2-wire cJTAG protocol to the 5-wire protocol used by the MCU
  • There’s a lot to the cJTAG and a 2-wire to 5-wire conversion is more complicated than one might imagine.

I believe that the JTAG 1149.7 protocol was designed to coexist with existing 1149.1 standard, and therefore

a 1149.7 compliant TAP controller may well need to have extra complexity to deal with handling the two protocols.

This leads me to think that the XDS110 may need to provide the necessary hand-shaking so that a 1149.7 TAP

controller can switch from JTAG to cJTAG.

I'm hoping to keep the 2-wire to 5-wire conversion as simple as possible,

so I'm wondering if I can simply assume an Oscan-1 format as shown below where:

  • I assume a triplet (scan-packet) is incoming to the chip from the XDS110
  • During the first 2 TCKC low intervals of the triplet I sample TMSC (for nTDI and TMS)
  • And during the 3rd TCKC low interval of the triplet I output TDO
  • And I forward on the 3rd TCKC pulse to the MCU.

Can I get away with this simplistic approach?

And if so, what timing can I expect on TMSC w.r.t. TCKC (output from XDS110)

and what timing must be met when TMSC is returned to the XDS110.

Any assistance you can offer would be most appreciated.

Thank you.

Andrew

  • 0
    TI__Guru 71835 points

    Andrew,

    Can you let me know which TI MCU core you are using?  I want to get this routed to the correct team inside TI.

    I believe 2pin cJTAG has to be supported by the MCU itself, I'm not exactly clear what could be done if only the 4 pin is supported by the MCU since it will expect all pins to be driven in the correct sequence.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 40 points

    I'm using a legacy 8051 design which only supports 4/5-wire JTAG.

    I was hoping that I could:

    • have a 2-wire cJTAG interface into the chip
    • have a state-machine (inside the chip) that converts the Oscan-1 format to the 4/5-wire format used by the MCU

    I can't imagine I am the first to want to use a 2-wire protocol with a legacy 4/5-wire TAP-controller.

    One thinks it might not be too difficult for a state-machine to convert one to the other. But I may well be overly optimistic Slight smile

    Andrew

  • 0 in reply to Andrew Hana
    TI__Guru 71835 points

    Andrew,

    I re-read your original post and now understand a bit better what you are trying to do.  Agree that a state machine can do the job of going back and forth across the standards and drive the appropriate pins on the embedded MCU in your design.

    I'm not familiar enough with the APIs/drivers that Code Composer(the TI IDE) uses to modulate between the different modes of JTAG on the TMDSEMU110, this is a drop down setting that we pick when we are configuring our target before run time.  In your scenario I think you would just use as 2pin mode always since those are the only pins brought out to the PCB.

    Not to get into this too much, but our E2E is structured around support of our ICs, any TMDSEMU question will get routed to the IC team that is the target for the Emulator for support connecting to that emulator.  This got routed to the C2000 MCU forum, I'm assuming due to the keywords in your original post(microcontroller). 

    So, I don't think there is a more appropriate forum to push this thread to.  Certainly it will be visible to the community and they are free to post with any help/experience they have.

    I think you might have more success contacting a dedicated emulator house such as https://www.blackhawk-dsp.com/ who might be able to guide you to the correct path or have more support since they make emulators to interface with various IC manufacturers(including TI). 

    I realize that we sell the TMDSEMU110 as a standalone product, but our scope is to support it for use with our devices.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 40 points

    Thank you for your response.

    Let me ask a couple of questions anyways ... and I'll see what responses I get (fingers crossed Slight smile)

    If we consider this plot:

    It seems that the TSMC data is only driven when TCKC is low (so as to avoid bus-contention issues)

    1) From TCKC falling, what is the output-delay (from the TMDSEMU110) (TCKC falling to TMSC valid) (that is, how long after TCKC falls must the target wait before sampling TSMC (to get nTDI and TMS)?

    2) From TCKC falling, when must the target device have TDO data (on TMSC) valid (an input delay spec) to ensure valid sampling by TMDSEMU110?

    3) When put into Oscan-1 mode, does the TMDSEMU110 do any handshaking first to indicate to a 1149.7-compliant TAP controller to operate in 2-wire mode?

    Any support would be most appreciated.

    Thank you.

    Andrew

  • 0 in reply to Andrew Hana
    TI__Guru**** 159715 points

    Andrew,

    A couple of things on the XDS110.  First as Matthew mentioned the software for it is only licensed for use with TI MCUs and processors.  Second we have not implemented support for 8051 in it.

    You might want to see what Keil or Segger have.  Both of them used to have debug probes that supported 8051.  If there was even a low pin count debug interface for 8051 then they may support it.

    Regards,

    John