2386639_en-US

[#1]

External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals

Hello,

I am trying to connect an external JTAG debugger to the FRDM-i.MX95 board.

According to the board schematic, the JTAG/DAP signals appear to be routed to test points on the PCB, and some related components are marked as DNP.
Based on this, I modified the board as follows:

Connected the JTAG signals from the test points
Mounted the DNP resistors related to the JTAG/DAP signal path
Added a connector for an external debugger
Connected VTref, GND, TCK, TMS, TDI, TDO, and RESET to the external debugger

However, I cannot observe the expected JTAG signal output from the debugger/board side.
For example, TCK/TMS/TDI do not appear as expected during the debugger connection sequence.

Could you please confirm the following points?

Is the above modification method correct for connecting an external JTAG debugger to the FRDM-i.MX95 board?
Are there any additional resistors, jumpers, solder bridges, or board modifications required to enable the external JTAG/DAP interface?
Is there any requirement for VTref voltage level or power sequencing before the external debugger starts driving JTAG signals?
Does the i.MX95 on FRDM-i.MX95 require any boot mode, fuse setting, security setting, or software initialization before the JTAG/DAP interface becomes accessible?
Can the external JTAG debugger access the Cortex-A55, Cortex-M33, and Cortex-M7 cores directly on this board, or is additional initialization by the bootloader/firmware required?
Is there any recommended connector pin assignment or reference modification guide for using an external debugger with FRDM-i.MX95?

I would appreciate it if you could provide any guidance, schematic references, or required modification details for enabling external JTAG debugging on the FRDM-i.MX95 board.

Best regards,

Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals

1. Is your modification approach correct?

In principle, yes.

If the FRDM schematic exposes:

• TCK
• TMS
• TDI
• TDO
• nTRST or RESET
• VTref
• GND

through test points and DNP stuffing options, then routing those signals to a connector is generally the correct approach.

However, I cannot confirm that all required DNP resistors have been populated because the schematic itself was not returned by the search results. The user manual does not contain the JTAG circuitry.

2. Why would no TCK/TMS/TDI activity be seen?

Normally, when a JTAG probe is connected:

• TCK/TMS/TDI are driven by the debugger.
• The target board does not generate them.

If you see absolutely no toggling on TCK/TMS:

Most common cause #1: VTref not detected

Many probes (Lauterbach, J-Link, PE Micro, ULINK, etc.) will not drive JTAG pins until VTref is present and within a valid range.

Check:

• VTref voltage at the connector.
• Common ground connection.
• Probe software reports the target voltage.

For FRDM-i.MX95, the DAP I/O supply appears related to the 3.3 V domain (NVCC_CCM_DAP). The board documentation shows this domain powered from VDD_3V3.

Most common cause #2: Board not powered

Most debuggers use VTref for sensing only.

They do not power the target.

Verify:

• Board powered from J25.
• PMIC started.
• VDD_3V3 present.
• Board LEDs active.

The board requires external PD power.

Most common cause #3: Missing signal routing rework

If the JTAG path contains:

• 0-Ω DNP resistors
• isolation resistors
• alternative stuffing options

then missing even a single resistor can leave TCK/TMS disconnected.

Since the schematic is not available in the search results, I cannot verify the exact resistor population list.

Most common cause #4: Wrong pin mapping

Verify with an ohmmeter:

Probe pin → connector pin → resistor → test point → i.MX95 ball.

Do not assume the test point labels match standard ARM 20-pin ordering.

3. Is a special boot mode required?

For a non-secure device:

No boot mode should be required just to observe JTAG clock activity.

TCK/TMS should toggle as soon as the debugger detects VTref and starts a scan sequence.

The boot switches affect:

• eMMC boot
• SD boot
• serial downloader

and are unrelated to whether the debugger generates TCK.

4. Are security settings/fuses involved?

Potentially.

The i.MX95 implements authenticated debug and debug access control. [i.MX95RM_Rev4 | PDF], [i.MX95RM_Rev2 | PDF], [i.MX95 Sec...2026-final | PowerPoint]

However:

• Security settings would usually prevent successful debug access.
• They would not normally prevent the debugger from generating TCK/TMS itself.

Since you report no TCK activity at all, I would first investigate:

1. VTref
2. Probe configuration
3. Cable pinout
4. Missing population options

before suspecting security.

5. Can A55, M33, and M7 be debugged?

The i.MX95 debug architecture supports:

• Cortex-A55
• Cortex-M33
• Cortex-M7

through the CoreSight/DAP infrastructure. [i.MX95RM_Rev2 | PDF], [i.MX95RM_Rev5 | PDF]

So from a silicon capability perspective, yes.

Whether all domains are immediately visible depends on:

• system state,
• security configuration,
• debugger support.

But no additional bootloader initialization is generally required for the debugger to detect the DAP itself.

Recommended measurements

Before further board rework, I would check:

Power

• VTref = ? V
• VDD_3V3 present
• Board booting normally

Continuity

• TCK connector ↔ SoC path
• TMS connector ↔ SoC path
• TDI connector ↔ SoC path
• TDO connector ↔ SoC path
• RESET connector ↔ SoC path

Probe side

• Does the debugger software report target voltage?
• Does it show "target detected"?
• Does it report JTAG chain scan attempted?

Oscilloscope

Probe directly at:

• debugger connector pin
• SoC-side test point

during connect attempt.

If TCK is present at the debugger connector but absent at the SoC test point, the issue is almost certainly in the board rework.

Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals

Thank you for your support.

We reviewed our external JTAG debugger connection and found that the
issue was caused by the wiring length between the FRDM-i.MX95 board and
the external JTAG debugger.

After shortening and rearranging the JTAG signal wires, the debugger was
able to detect the target correctly and the JTAG signals were observed as
expected.

Therefore, this issue has been resolved by improving the JTAG wiring
length and connection quality.

Thank you again for your assistance.