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.
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,
Refer below inputs for the JTAG connection related queries.
FAQs for reference related to JTAG, TRST, boundary scan, connector
[FAQ] AM625: jtag schematics to implement in customer board
e2e.ti.com/.../faq-am625-jtag-schematics-to-implement-in-customer-board
e2e.ti.com/.../tda4vm-which-debug-signals-are-required-in-mass-production
AM625: JTAG TRST signal pull down.
e2e.ti.com/.../am625-jtag-trst-signal-pull-down
AM623: AM6232ATCGGAALW JTAG Boundary Scan
e2e.ti.com/.../5011656
AM623: AM623, 10-pin JTAG adaptor and TRSTN
e2e.ti.com/.../am623-am623-10-pin-jtag-adaptor-and-trstn
AM625: nTRST pin pulled low
(+) AM625: nTRST pin pulled low - Processors forum - Processors - TI E2E support forums
JTAG - pull resistor requirements
Do TMS, TCK, TDI and TDO need a pull-up?
Minimum recommendation is pull down resistor on TRSTn, pull-up resistor on TCK, TMS, and TDI. A pull resistor on TDO is optional.
About JTAG signals
The internal PU/PD of the JTAG signals ON state even during a reset, and it is possible to keep the internal PU/PD ON state even after a reset, but if system does not use JTAG feature, does JTAG siginals need to connect to external PU/PD ?
Customers may think that the internal PU/PD is sufficient for signals processing, but customer want to confirm as double-check.
The customer also connects the TRST pin to an external PD. The purpose is to ensure that the TAP controller is stopped. Is there any problem in processing this?
The internal pulls are turned on by default during and after reset. They will remain on as long as software doesn't turn them off.
External pulls are recommended anytime PCB traces are connected to the JTAG pins. The internal pulls are weak and they are not true linear resistors. They get weaker as the voltage approaches the voltage rail the resistor is pulling toward. Therefore, the internal pulls may not be able to hold signals in a valid logic state when external noise sources couple into the PCB signal traces.
The external pulls should be connected to the same power rail as the internal pulls. For example, the EMU[1:0], TCK, TDI, TDO, and TMS pins are pulled to VDDSHV_MCU and the TRSTn pin is pulled to VSS.
The customer should consider inserting a low pass filter on the TRSTn signal near the AM62Px pin, by inserting a 100 series resistor on TRSTn signal with a 0.1uF shunt capacitor on the processor side of the series resistor. I have seen external noise events couple into the TRSTn signal and creating random resets of the TAP controller while operating a debugger. This low pass filter will block transient noise events that cause unexpected resets to the TAP controller."
"Customer wants to double check.
Is the below understanding correct ?
If system does NOT use JTAG, i.e. PCB traces are NOT connected to the JTAG pins, the internal PD/PU can be used.
So , external PD/PU is NOT required when JTAG is not used.
If system uses JTAG, i.e. PCB traces are connected to the JTAG pin, the external PD/PU should be used.
That is correct. However, they would never be able to connect a debugger to the device if they do not connect PCB traces to JTAG."
Boundary scan for AM62
Please refer to Debug Boot Modes and Boundary Scan Compliance section (13.3.4) in the AM62x TRM.
The boundary scan tool must set the EMU pins to the appropriate value before the rising edge of TRSTn to select the boundary scan TAP controller.
Boundary Scan
This device supports boundary scan using an IEEE 1149.1 compliant JTAG TAP that is made visible through the
use of a compliance-enable mode (see Section 13.3.4). IEEE 1149.1 and 1149.6 Boundary Scan support are
defined in device-specific BSDL files that can be found in the respective device’s product folder on ti.com.
SoC Address Space
The device architecture provides access to On-Chip debug resources through the SoC Address Space. This
includes access to all DAP Access Ports (APs) as well as the Debug-APB address space.
13.3.4 Debug Boot Modes and Boundary Scan Compliance
The EMU1 and EMU0 device pins are used to convey debug boot mode behavior and can also be used as part
of a boundary scan compliance sequence to enable boundary scan features.
Debug & pins for connector
Concerning debugging, it's not very clear in the documentation, for the JTAG and TRACE, are the 2 used for ARM and DSP?
The number of pins required is significant, on the eval board it's a 60-pin connector, but they're not all used, so we can optimize, but even then it's still a lot of pins, aren't there any optional signals? Do we have to have everything? What surprises me is that some signals can be output on 2 different pins (table 6-115 of the datasheet).
Regards
JTAG signals (TRSTn, TCK, TMI, TDO, TDI) can be used to access any processing core within the device (includes ARMs and DSPs). You can access all registers, internal memory, etc. Standard debugger functionality. TRACE is used to collect information captured/logged by the processing core and off-loaded to external debugger for history, inspection, etc. Signals include CLK, CTL, and configurable data widths based on needed bandwidth. TRACE is an optional interface, but it is recommended to support JTAG as a minimum for debug.
Our EVM uses MIPI-60 connector for JTAG + TRACE. There are other connector standards for mating with debuggers which have only JTAG and thus fewer pins.
Regards,
Sreenivasa
Hi Board designers,
Additional inputs for AM64x
AM6442: For JTAG connector,TRST and TCK should pull up or pull down?
e2e.ti.com/.../5345412
AM2434: How to do boundary scan testing
e2e.ti.com/.../5165506
Regards,
Sreenivasa
Hi Board designers,
Additional inputs for Boundary Scan
AM625: Availability of Boundary Scan if JTAG is locked
we assume, that the boundary scan feature is NOT available if JTAG is locked in terms of security. On the other hand, if we unlock a previously locked device by, e.g., injecting a debug-certificate, boundary scan would be available again, too.
Are those assumptions correct?
Boundary scan functionality remains available for use, however downstream debug features that are typically available via JTAG are locked out.
Boundary scan on HS-SE and TI-dummy key hardware TDA4VM
With the JTAG locked down on TI-dummy key hardware and HS-SE hardware variants, is boundary scan functionality also included in the JTAG lock down? If the answer is no, what would TI recommend be the factory process for performing boundary scan with these hardware variants? (for the sake of this question, it can be assumed that the HS-FS component has had the eFuses blown to make it an HS-SE before boundary scan is run)
Boundary scan is *not* locked on HS devices.
Please confirm if Boundary Scan is possible for HS-SE device( without unlocking JTAG ) at manufacturing.
Yes, BSCAN can still be used.
We want to define the power up sequence for the boundary scan test on the TDA4VM.
We were wondering if we should power up the board from the input power such that the PMICs can enable the various rails
or should we apply voltages to the various rails through the test points? Or are there other methods to do the boundary scan?
The power levels and sequence requirements for the standard operating mode and the boundary scan test are the same.
No change in voltage levels for each power rail, no change in power sequence, and no change in which rails are required to be powered.
AM2431: What does this boundary scan function refers to
e2e.ti.com/.../am2431-what-does-this-boundary-scan-function-refers-to
Boundary Scan
e2e.ti.com/.../am623-jtag---boundary-scan
AM6548: Boundary scan for HSFS on AM65x
e2e.ti.com/.../am6548-boundary-scan-for-hsfs-on-am65x
JTAG Boundary Scan functions should work the same way irrelevant of device types (GP or HS) i,e, JTAG Boundary Scan should always work. On the other hand, JTAG Debug Access depends on device types (GP or HS)
e2e.ti.com/.../am625-boundary-scan-issues
AM625: Boundary scan issues
AM623: If CSI is not used but boundary scan is what to do with W13, W14?
e2e.ti.com/.../am623-if-csi-is-not-used-but-boundary-scan-is-what-to-do-with-a8-and-a10
AM62P5-Q1: Z1: HW: JTAG boundary scan on HS devices
e2e.ti.com/.../am62p5-q1-z1-hw-jtag-boundary-scan-on-hs-devices
AM2434: JTAG boundary scan and debug info/capabilities
e2e.ti.com/.../am2434-jtag-boundary-scan-and-debug-info-capabilities
Regards,
Sreenivasa
Hi Board designers,
Additional inputs for EMU0/EMU1 Connections
AM62A3-Q1: HW: When not using the JTAG port
If JTAG is not used, is it OK to leave EMU0/EMU1/TCK/TDI/TMS/TDO/TRSTn open?
Are you connecting any PCB traces to these pins? If so, they need external pull resistors to help hold a valid logic state. If not, you can leave them unconnected. However, this is very risky as you will never be able to connect a debugger to find what is happening if your system has problems.
No PCB traces.TRSTn uses internal pull-down, other uses internal pull-up to open the balls.
This is OK?
Yes, as long as you do not connect any PCB trace to these package terminals.
We expect external pulls to hold a valid logic state on these pins when any PCB trace is connected because the
internal pull resistors are weak and non-linear. We make this recommendation because electrical noise could couple on the un-driven
PCB traces and the internal weak pull resistor may not be able to hold a valid logic state. The internal resistor should be able
to hold a valid logic state if no signal trace is connected to the terminals.
This topic is addressed in the datasheet "Connectivity Requirements table.
AM62] EMU0 / EMU1 with JTAG
Could you tell us what additional features/data are availables whilst using the EMU0 and EMU1 in addition to the Normal JTAG ?
The emu0/1 signals have 2 purposes. One is to control the device behavior upon booting; please refer to the AM62 TRM, section 13.3.4.
The other adds cross-triggering capabilities for real-time debug purposes; please refer to the TRM section 13.3.6.
TDA4AL-Q1: Are EMU0/EMU1 pins essential for On-chip Debug?
Are EMU0/EMU1 pins essential for debugging a TDA4AL HS system using CCS/XDS560v2?
These pins seem to optional according to some articles available on the Internet.
Could we safely block these pins so that these pins are not connected to the emulator?
(There are some limitations on the routing traces of the next board iteration, so it is desirable not expose EMU0/EMU1)
EMU0, EMU1 can be used to halt the processor prior to ROM execution.
This is sometimes important if debugging security issues, as that can impact access to the device via JTAG. If needed to debug initial boot/security issues - then I would recommend supporting. If debug efforts are beyond that (more application/peripheral level) then may not be needed.
As per your reply, typical R5 SBL and boot app debugging sessions have nothing to do with the EMU0, EMU1 pins?
The EMU0/EMU1 pins are not JTAG and are not part of the TRACE logging interface (TRC).
They are available in the Debug IP can be setup for generic triggers.
TDA4VM-Q1: BSDL test point
Our customer is preparing do BSDL test and find they don't place test point on EMU1. Which part of test coverage will drop if BSDL is not tested? Do we have the document/guide to elaborate the hardware configuration of Jacinto BSDL test?
On TDA4VM (J7ES) it is required to have EMU1=0 at POR to enter BSDL mode. They will not have access to boundary scan if this is not available.
The public BSDL file for TDA4VM is here www.ti.com/.../sprm751
It gives details of what pads are on the chain. Its compliance pattern does call out EMU1=0 for mode entry.
attribute COMPLIANCE_PATTERNS of J721E : entity is "(ddr_ret, porz, mcu_porz, reset_reqz, mcu_resetz, emu0, emu1)(0111110)";
There are several domains and multiple function modules in the SoC. Customer would to like to know which parts that BSDL test can cover?
Customer want to evaluate the impact if they cannot run the BSDL test.
Production chips on a customer board will only be able to test the actual IOs on the scan chain.
Some customers use this to look for open/shorts on the PCB, additionally some use BSDL as a backup way to bit-bang burn a flash chip on a board.
TDA4AH-Q1: usage of EMU[1:0] TI extensions
what is the usage of the EMU[1:0] TI extensions lines? On our board we have no possibility to connect them to the JTAC . We plan to connect them to a fixed level via resistor. From the EVM page 4514 it seems that connecting both to high is a good idea? What will we lose with having no connection to a connector?
Both EMU0 and EMU1 should be pulled high via a 1K-ohm to 10K-ohm resistor for default settings/productions systems.
EMU0/1 on DEV systems should be exposed and settable. They get used to:
Signal BSDL mode entry (POR latched) used for open/short testing and possible flashing
Signal WIR mode entry (POR latched) which can be used to run bare metal code used with char projects
Without this a working firmware and basic boot image have to be golden.
This can be a chicken and an egg for a new board.
WIR also allows initial flash burning on an HS boards using JTAG
The alternate is to ensure a UART boot is possible + a stable boot image + stable flasher in that boot image.
The above can have lots of detail issues which a JTAG burn totally bypasses
Run time external trigger sources used in conjunction with debugger and external devices
Run time (non-por related)
MCU-PLUS-SDK-AM243X: hardware JTAG debug emu0 emu1
e2e.ti.com/.../mcu-plus-sdk-am243x-hardware-jtag-debug-emu0-emu1
EMU0/1 is useful externally for:
Wait-in-Reset (WIR)
Useful on HS devices for early board checkout and JTAG flashing
Boundary Scan
Useful for old style open/short testing and flashing burning
Debug-Triggers
Can be input our output triggers linked to different debug actions
Therefore, we encourage you to connect the EMU[1:0] pins to the debug connector and use external pull-ups to hold these signals high when not connected to a debugger.
e2e.ti.com/.../4424403
AM2434: In JTAG debugging, how can I connect EMU0 and EMU1?
e2e.ti.com/.../am625-am6254x-emu0-emu1
AM625: AM6254X EMU0 EMU1
e2e.ti.com/.../sk-am62a-lp-am62a-series-mpu-jtag-connection
SK-AM62A-LP: AM62A series MPU JTAG connection
The JTAG connector sources power to the debugger because it has an internal level-shifter with its SOC port powered from the target. The buffer/level-shifter components in each JTAG signal path are also operating like a switch to select between the on-board debugger or the connector. Most customers place the connector within a few inches of the processor and connect the pins directly to the SOC, with the appropriate external pull resistors.
The signal trace length of 6 inches is not a firm requirement. Short signal traces will minimize signal distortion and signal propagation delay. The most important thing is making sure the clock signal doesn't have any non-monotonic transitions. You can always resolve timing issues by slowing down the operating frequency of TCK from the debugger.
e2e.ti.com/.../5043123
AM62A7: AM62A AXI bus access doesn't show anything
The solution was to use WIR mode to get near GP accessibility. To get this state EMU0=0 and EMU1=1 needs to be driven. With that configuration now registers are accessible.
e2e.ti.com/.../5031751
TDA4VH-Q1: Debugger Header options
Regards,
Sreenivasa
