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.

TMS320C6748: Issue with JTAG Connection Between TI XDS110 and TMS320C6748 DSP

Part Number: TMS320C6748
Other Parts Discussed in Thread: SN74AXC4T774EVM,

Tool/software:

Setup

I'm trying to connect the TI XDS110 Debug Probe to the TMS320C6748EZWT3 DSP over JTAG, but I keep running into issues. The JTAG signals on my board are running at 1.8V, as shown in the attached schematic.

What I’ve Tried

  • Direct Connection (XDS110 → DSP)

    • Connected the XDS110 debugger directly to my board’s JTAG header.
    • In Code Composer Studio (CCS), the Test Connection was successful.
    • However, when trying to connect to the DSP, I get error -6305: "PRSC module failed to write to a router register", and the connection fails.
  • Using a Level Shifter (SN74AXC4T774EVM)

    • Since XDS110 is known to work at 3.3V, I used a level shifter to convert signals between 3.3V (XDS110) and 1.8V (DSP).
    • The following JTAG signals go through the level shifter:
      • TMS, TDI, TCK, TDO, TRSTn
    • Direction Setup:
      • TDO: DSP → Debugger (B to A)
      • TDI, TMS, TCK, TRSTn: Debugger → DSP (A to B)
    • Power Setup:
      • VCCA = 3.3V, VCCB = 1.8V
    • Pull-ups:
      • I hand removed the built-in pull-ups on my board.
      • Added external pull-ups to 3.3V for TDI, TMS, and TCK using a custom breakout board.
      • Connected pin 5 of XDS110 to 3.3V through a 100Ω resistor.
    • Results:
      • Test Connection succeeds in CCS, but I still can’t connect to the DSP (same error as before).

Questions

  • The fact that the Test Connection succeeds makes me think the JTAG signals are reaching the board.
  • What could cause error -6305? Could it be pull-up resistors, signal integrity, or a security setting on the DSP?
  • Has anyone used XDS110 with TMS320C6748 at 1.8V JTAG?
  • Is there a recommended level shifter setup for this case?

Any help would be really appreciated!

  • Hi, checking internally, please allow us few days before coming back to you.

    Thank you,

    Paula

  • Thanks. Please let me know as soon as possible.

  • You did not connect pin 5 of the 20-pin JTAG connector to your JTAG IO power supply, so the debugger doesn't know you are operating at 1.8V.

    Note: You have a 4.7K pull-up and optional 2.2K pull-down on the EMU[1:0] signals. Installing the pull-up and pull-down resistors at the same time would create a mid-supply voltage on the EMU inputs. You should remove the pull-up when installing a pull-down to prevent the input from be at a mid-supply voltage.

    Regards,
    Paul

  • Hello Paul, 

    Thank you for your reply. 

    I am connecting the XDS110 debugger to the JTAG port on my custom board using a 20-pin to 14-pin adapter board (PWB 510401). 

    • Pin 5 of the 14-pin adapter board is directly connected to pin 5 of the 20-pin JTAG connector.
    • If you check my schematic, pin 5 of the 14-pin JTAG header is connected to 1.8V via a 100Ω resistor.

    Regarding your additional note: 

    • The 2.2kΩ pull-down resistors on the EMU[1:0] signals are not populated (DNP) on the board.
    • These two signals are only being pulled high by the 4.7kΩ resistors.


    Thanks for taking the time to respond. 

    Albi.

  • I'm sorry, for some reason I got my pin numbers mixed up and thought the no-connect was pin 5 and didn't notice it was connected to the 1.8V supply via a 100ohm resistor.

    Where did you connect the RTCK signal?  

    Have you tried to reduce the operating frequency of the TCK to a very low rate to see if you are having a signal quality or timing issue?

    Have you used an oscilloscope to check signal quality and timing?

    Regards,
    Paul

  • Hello Paul.
    The RTCK signal is connected to pin 9 of the 14pin header in the board, which is also connected to pin 14 of the 20 pin header. In the board there is a 22Ohm resistor in series with RTCK. 

    I have reduced the operating frequency of the TCK to about 200kHz. It cannot go lower that 200kHz. 

    I am attaching some scope images for RTCK as well as TCK signals.

    RTCK:

    TCK:

    I have tried lowering the value of the pull up resistors for the TDI, TMS, and the TCK to 4.22kOhm (originally it was 10kOhm, highlighted in yellow in screenshot below). But still I get the same error on CCS and unable to connect. 

    I really appreciate your help.

  • These scope shots have minimum value. We need to see a very high-resolution capture of the rising and falling edges of TCK taken near the processor pin to determine if there are any non-monotonic events on the transition. We also need to see the timing relationship of TCK to TDI and TDO to confirm there is enough setup and hold margin.

    The way you are looping RTCK back from TCK without a buffer is likely creating signal distortion for the processor TCK input. This is why I need to see a high-resolution capture of the rising and falling edges of TCK taken when probing near the processor TCK pin.

    What is the JTAG IO voltage (DVDD3318_B) in your system? 

    Regards,
    Paul

  • Hello Paul. 

    I have collected more scope images to see the timing relationship between TCK - TDI and TCK - TDO. 

    TCK - TDI:

    Setup Time



    Hold Time

    TCK - TDO:

    Setup time

    Hold Time

    "The way you are looping RTCK back from TCK without a buffer is likely creating signal distortion for the processor TCK input." The JTAG pins are fed straight into the C6000 pins - TCK and RTCK lines are separate. Are these two lines supposed to be buffered? There reference design for the EVM does not suggest buffering of these two signals. 

    DVDD3318_B in my system is fed by 1.8V. This is the only difference between my custom board and the reference design for the C6748 EVM board.
    I am strongly starting to believe that the fact that I am referencing 1.8V to Power group B (which JTAG pins are part of) it's making the JTAG communication to not work. 

    Have you ever make a C6000 chip JTAG pins work with 1.8V?

    (P.S. I mistakenly marked your response as "Resolved my issue", but unfortunately I am still having problem and so far I am getting the same errors)

    Your help is truly appreciated.

    Albi

  • You scope captures are showing data changing on falling edge of clock and I know data is captured on the rising edge of clock. Therefore, you have lots of setup and hold margin at this operating frequency. I do not see any obvious signal integrity issue, but there is not enough resolution on clock rise/fall edges to be sure.

    I do not have any personal experience using the TMS320C6748 device. It is an old design that was passed down to our team for support. This thread was assigned to me because I support any questions related JTAG signal timing and electrical characteristics for our newer processors. I do not have any experience using the debugger tools. I do not see anything obvious wrong with the signals.

    I feel there may be an issue with RTCK. Does the debugger software allow you to configure it to use its own TCK as its TDO capture clock rather than use RTCK as its TDO capture clock? If so, can you change this configuration to see if it works. 

    Are you saying the TCK signal coming from the debugger is only connected between pin 11 of the JTAG connector and pin J15 of the TMS320C6748 device, and the RTCK signal going to the debugger is only connected between pin 9 of the JTAG connector and pin X of the TMS320C6748 device?

    I found some indication that pin K17 of the TMS320C6748 device may be shared between the RTCK and GP8[0] signal functions. However, I was not able to find any specific statement in the datasheet or TRM that defined the default signal function of K17. Are you assuming pin K17 is sourcing RTCK by default. If so, where did you find that information?

    Regards,
    Paul

  • Hi Paul, 

    I feel there may be an issue with RTCK. Does the debugger software allow you to configure it to use its own TCK as its TDO capture clock rather than use RTCK as its TDO capture clock? If so, can you change this configuration to see if it works. 

    I would not prefer to change the clock configurations of the debugger, and to be honest I am not too familiar on how to do it either. One thing I can tell for sure that the same debugger (XDS110) that I am using for my custom board, works fine on the EVM LCDK6748 board (which has the exact same chip as I am using in my custom board). The only difference between the two board is that the EVM JTAG pins are pulled up to 3.3V, whereas on my custom board the JTAG pins are pulled up to 1.8V (because of DVDD3318_B being supplied by 1.8V instead of 3.3V).

    Are you saying the TCK signal coming from the debugger is only connected between pin 11 of the JTAG connector and pin J15 of the TMS320C6748 device, and the RTCK signal going to the debugger is only connected between pin 9 of the JTAG connector and pin X of the TMS320C6748 device?

    Yes, TCK is connected between pin 11 of the JTAG connector and pin J15 of C6748. TCK is pulled high via a 10kOhm resistor (highlighted in green) and there is a series resistor (highlighted in yellow) between pin 11 of the JTAG connector and pin J15 of C6748. 

     

    RTCK is also connected only between pin 9 of the JTAG connector and pin K17 of C6748. There is a series resistor (highlighted in yellow) connected in between. This signal is not pulled high or low. 

    I have found this document (link here:https://www.ti.com/lit/an/sprack9/sprack9.pdf?ts=1740126203979&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FOMAP-L137) that states " a simple loop from the TCK pin to the RTCK pin of the XDS connector with a series termination resistor is all that is required. Normally a 22Ohm termination resistor is sufficient". 

    I have not been able to find information regarding the default state of pin K17. I am following the reference design for the EVM board where the RTCK signal is connected to this pin as well. 

    I am currently running some tests on the EVM board to test the timing relationship between TCK and TDI as well as TCK and TDO. I aim to compare these results to the ones I got from my custom board. 

    Again, your help is much appreciated. 

    Albi.

  • Hello Paul, 

    Just wondering if you have any comments regarding my last message. 

    Thanks!

  • I'm not sure what could be causing your issue. I asked someone else that has experience using JTAG debuggers with our older processor if he could take a look at this thread and offer any suggestions. However, he is out of the office with plans to return on 2/26.

    Regards,
    Paul

  • Thanks Paul. Please keep me posted.

  • Hello Paul. Please let me know if the other person has returned back to the office and they are able to review this thread and provide any recommendations.

  • He finally replied late today. As I mentioned before, I'm not familiar with using the debugger tools. Therefore, I'm going to copy and paste most of what he said hoping it helps you.

    He has an EVM and recently connected to both the ARM and the DSP using a Lauterbach debugger, so he knows JTAG connectivity works on the device. 

    He had to first connect to the ARM and configure clock to the DSP (via a startup script) before trying to connect to it. He said it appears you are only pinging the DSP and would like to know why you do not connect to the ARM first, or better yet try to attach to the DAP target. He is speculating your other board may have some code that is initializing things. The DAP target (and ARM) requires less setup than the DSP as the ARM is the boot master.

    The CCS messages about not being able to program the router actually seem more like a TAP level problem with linking the DSP into the chain. Since your connection test passes probably the TAP->to-IDCODE is fine (which means communication is fine). The issue per the ‘message’ would seem to indicate the CCS driver isn’t dynamic linking the DSP. But maybe the message is not useful… I’m not sure.

    • As I mentioned I’d first try the DAP target
    • Then try the ARM and run the bare metal GEL setup to ensure the DSP is on
    • Then try to connect to the DSP.

    I hope this helps.

    Regards,
    Paul