Tool/software:
Hi TI Experts,
I have the below queries regarding the use of JTAG interface
JTAG connection recommendations
Connections to support Boundary scan
JTAG connectors
Let me know your thoughts.
Hi Board designers,
Additional inputs for AM64x
AM2434: How to do boundary scan testing
e2e.ti.com/.../5165506
For JTAG connector, TRST and TCK should pull up or pull down?
The AM62x TRSTn signal should have an external pull-down on it and the other JTAG signals should have external pull-ups on them, including the EMU[1:0] pins. This prevents the JTAG pins from floating when a debugger is not connected.
The IEEE 1149 specification recommends pull-ups on all of the JTAG signals. However, TI doesn't follow that recommendation for TRST. We recommend TRST to be pulled low to hold the JTAG TAP controller in reset during normal operation to prevent any chance of noise generating conditions that cause the debug or boundary scan functions to do something unexpected. The only side-effect associated with not following the IEEE 1149 recommendation is some debuggers may need to be configured to operate their TRST output in push-pull mode if they default to open-drain mode. The debugger TRST output needs to operate in push-pull mode so it can drive the TRST signal high.
Thanks for the clarify, what about TCK?
A pull-up, as recommended by the IEEE 1149 standard.
Regards,
Sreenivasa
Hi Board designers,
Additional information for enabling boundary scan using EMU0..1
The BSDL model (bsm) found online does not work
Can you please confirm if you have changed the logic states applied to the EMU[1:0] inputs to place the device in boundary scan mode?
Refer Below and TRM for more information.
Regards,
Sreenivasa
Hi Board designers,
Refer below information related to RTCK.
We are referring the below document for the layout guidelines for JTAG interface of DSP part TMS320C6416TBCLZD1.
Document URL: www.ti.com/lit/ug/spru641/spru641.pdf?ts=1737350351360&ref_url=https%253A%252F%252Fwww.google.com%252F
Do we need to length match return signal path of TCK with the path of actual TCK? Please refer the below image for return signal path of TCK.
The JTAG peripheral changes signals on the falling edge of TCK and latch signals on the rising edge of TCK. Therefore, you can always resolve any setup time or hold time violations by reducing the frequency of TCK. This eliminates any need to limit or match trace delays as long as you are willing to reduce the operating frequency of the JTAG peripheral.
Some debuggers can be configured to use RTCK as the capture clock for the TDO signal, as a way to compensate for round trip PCB and cable delays. This may allow the JTAG peripheral to operate at a higher frequency. The real benefit is when the target device has a RTC output signal that also compensates for the delay introduced by the target device. The TMS320C6416 device doesn't provide the RTCK output, so one option is looping the TCK signal back to debugger. However, this option can be problematic. The debugger may support a configuration option that uses its own TCK signal as the TDO capture clock rather than the looped back TCK signal. If so, this may be a more reliable option because branching the TCK signal into two paths on the target PCB can introduce signal integrity issues on the TCK signal. It is very important that your PCB design doesn't introduce any signal distortion on the TMS320C6416 TCK input such that it sees non-monotonic transitions. You should simulate signal distortion introduced by your PCB design to confirm your design is robust if you loop the TCK signal back to RTCK.
Thanks for your replies and request you to provide us below inputs as well.
1. Are there any reference layout files with looped back TCK RET signal?
2. Whether TCK RET signal is compulsory to program TMS320C6416T DSP or TCK RET is just for increasing the speed of programming?
3. At which point in the trace of actual TCK, we need take looped back RET TCK signal?
This device pre-dates my support, so I'm not familiar with any PCB layout references. Use the method described in my answer to #3.
As mentioned in my previous reply, RTCK support may be optional for some debuggers. The RTCK signal was implemented to improve operating speed of the JTAG peripheral, but it may not be required for some debuggers. You will need to ask the debugger manufacture if the RTCK is required for their debugger to operate properly. It is not required by the TMS320C6416 device.
The buffer shown in the schematic snapshot inserted above would need to be placed very close to the TMS320C6416 TCK input pin such that each leg of the signal trace branch is very short and equal length (a short-T clocking topology). You should also include a pull-up on the TCK signal to ensure it is not floating when a debugger is not connected.
AM62A7-Q1: Multiple devices in JTAG scan chain
www.ti.com/.../spru655i.pdf
If there is additional insight regarding 2xAM62D's in the same JTAG scan chain, please pass along. For example, CCS/Emu support, further HW considerations, etc.
There is some information in the below document: dev.ti.com/.../node
See the section on "multiple devices". However, I think the information above may be a subset of what is already in the document you referenced.
As for information specific to multiple AM62s, I don't have any experience myself. Perhaps the device experts can share more information.
I'm not aware of anyone that has tried to connect two AM62Ax devices in the same JTAG scan chain. There should not be any hardware issue with connecting two in the same chain as long as the IOs associated with JTAG pins of both devices are powered from the same source. The IOs implemented in the AM62Ax devices are not fail-safe, so you must ensure no potential is applied to any of the IOs until the respective IO power rail is valid.
In our project, I'm also interested in this JTAG chain mode. From your reply, I think the HW can support the JTAG chain mode as long as it can meet some known HW rule. We can refer to the link :dev.ti.com/.../node
However, if we want to use the JTAG chain, we have to require that the Software IDE/CCS also can support it. How about your opinion/experience about it?
Ki is from the team that supports the software development tools. I can only answer questions related to electrical and timing requirements and characteristics of the JTAG peripheral. I do not know anything about how the software debug tools communicates with internal debug subsystem.
However, if we want to use the JTAG chain, we have to require that the Software IDE/CCS also can support it. How about your opinion/experience about it?
Code Composer Studio comes with all the necessary software/drivers for our XDS JTAG based debug probes.
I checked the link:www.ti.com/.../spru655i.pdf and XDS JTAG based debug probes.
It looks the 10pin connector will not support JTAG chain, is it right？
And the RTCK signal is necessary. However, I didn't find the RTCK pin in AM62D and AM62A. Do you know how to deal with it?
I'm not familiar with a 10-pin connector option. The document referenced in your previous reply describes a 14-pin, 20-pin, and 60-pin connector options. The document also tells you to connect RTCK to either a loopback of the emulation header's TCK or a target device-supplied RTCK. The AM62Ax devices do not implement a pin to source the RTCK signal, so you must loopback the TCK signal.
Q.) What is the purpose and function of EMU0, EMU1
EMU0, EMU1 are signals used to put processor in special test modes, and are typically not required for most developers.
Is it mandatory that RTCK should be connected to TCK?
I know if the JTAG target(TDA4VE) doesn't have RTCK port, we don't need to connect RTCK.
The reason why I asked, If we connect RTCK with TCK, our system may have long T-branch connection.
So if It is not mandatory, I don't want to connect it.
RTCK should be connected to TCK. See TI's EVM as an example of this.
RTCK requirement would be emulator dependent. As you stated, its not supported on the TDA4VE. It only needs to be connected if required by the connected emulator.
We are designing a custom board using AM2431
We refer to EVM circuit which is attached . In that pdf page no 23 JTAG section
We have some quires which We like to know things below
1. How 20 pin connector support JTAG and Emulator function
2. As we the requirement we don't have space for multiple device, So we are planning to remove the buffer . Does it cost any issue (as reference as block diagram)
3. RTCK loopback ,Do we need to add buffer in between
PROC101C(005)_SCH (1) 4.pdf
The buffers inserted in the TMS, TDI, TDO, and TRST signal paths are being used as level shifters to ensure the debugger does not applying any potential to the AM243x pins when the debugger is connected, and power is turned off to the AM243x device. The AM243x pins are not fail-safe, so your system implementation must never apply any potential to the AM243x pins when it is not powered. See the "Steady-state max voltage at all other IO pins" parameter in the Absolute Maximum Ratings table found in the AM243x datasheet.
The buffers in the TCK and RTCK paths provide the same voltage level translation function as well as preserving signal quality of the debugger clock source that needs to branch into to two paths, where one path sources the AM243x device and the other path returns a delayed clock to the debugger to improve timing margin at high operating speeds.
Your debugger may not require a RTCK. If so, you may not need to branch the debugger clock source.
Some debuggers have an internal level translator, where the same AM243x IO power source is routed to the JTAG header and powers the downstream side of the level translator in the debugger. If so, you may not need the level translators.
You need to understand these types of details associated with the debugger you plan to attach and design your system to accommodate the requirements of both AM243x and the debugger under all possible use cases. This is the system designer's responsibility.
Thank you for the response. We are using XDS110 debugger for custom design
Can we proceed with this debugger with our custom design.
Yes, you should be able to use the XDS110 debugger.
They should connect TMS, TDI, TDO, TCK, EMU0, and EMU1 from the connector directly to the AM62x device with separate external pull-ups on each of these signals.
They should connect TRSTn from the connector directly to the AM62x device with an external pull-down on this signal.
They will need to research the debugger expectation for the RTCK connection. Some debuggers may require a RTCK, while others have a configurable option to use it or ignore it. I have seen people simply loop TCK back to RTCK near the connector, but this can cause signal integrity issues. Splitting a signal trace like this can cause reflections that can introduce clock glitches. I suggest placing two resistors near the TCK connector pin and inserting one in series with the TCK signal connecting to the AM62x device and the other in series with the RTCK path when TCK is looped back to RTCK. This acts like series terminations and the resistor values can be adjusted to impedance match the signal transition into two paths which also attenuates any undesired reflections.
The supply connected to the debugger connector should be the same supply that is connected to IO power rail of the AM62x JTAG IOs (VDDSHV_MCU).
They should also reference the following document: Emulation and Trace Headers
Is JTAG RTCK required for target connection?
RTCK is not a standard JTAG signal. The asynchronous TAP controller does not require local synchronization, so the RTCK is not a MSUT.
But, occasionally a target device requires the JTAG interface to be externally synchronized to a clock within the device due to it being slow, non-continuous, or variable. The adaptive clocking feature uses the RTCK to address this requirement. When adaptive clocking is enabled, the debug unit issues a TCK signal and waits for the RTCK signal to return before sampling TDO.
If you emulator supports adaptive clock feature, and you are planning to use this feature, you need RTCK from the target device.
What are the differences between JTAG and ETM?
JTAG: The functionality usually offered by JTAG is Debug Access and Boundary Scan: 1. Debug Access is used by debugger tools (for example XDS110, XDS2x) to access the internals of a chip making its resources and functionality available and modifiable, e.g. registers, memories and the system state. 2. Boundary Scan is used by hardware test tools to test the physical connection of a device, e.g. on a PCB. This is usually not the task of a debugger tool.
ETM: The Embedded Trace Macrocell (ETM) interface enables you to connect an external ETM unit (for example XDS560V2 Pro) to the processor for real-time code tracing of the core. JTAG signals are also required for ETM trace.
Why should the nTRST signal be pulled LOW?
nTRST is JTAG “Test Reset”. It is low active. The nTRST is used for an asynchronous reset of the state machine of the JTAG Test Access Port (TAP). The debugger drives it by a push-pull driver. It resets the TAP by a certain JTAG sequence. The target device requires that the nTRST is first held low for a few TCK cycles and then raised after the TCK signal has started running, so the device can detect a rising edge on nTRST.
A pull-down resistor should be added onto nTRST on target side. It ensures the on-chip debug logic is inactive when the debugger is not connected.
From the debugger point of view, nTRST is optional.
The JTAG connection is lost after the program is loaded to flash.
The problem might be caused by the code you have programmed. The code in the flash makes the CPU enter an exception state repeatedly, and the CPU is not able to enter a debug state.
Please try this procedure to let CPU enter a debug state:
5. Please refer to the following link for more information to trouble shoot the JTAG connection issues:
https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html
Regards,
Sreenivasa
