TMDSEMU110-U: TMDSEMU110-U

Hi Zhang,

Two distinct faults appear in the session, and only one of them is fatal:

1. Fatal: CS_DAP_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP — the debug session reaches initialization but cannot reach the AM2631's Debug Access Port. Flashing then aborts on Cortex_R5_0 with Flash failed, error code: 1 1.
2. Configuration defect (non-fatal): Cortex_R5_2: GEL: Error loading file '...\emulation\gel\AM263x\CPU_RESET.gel': unable to open GEL file. The configured GEL path is broken and must be corrected or the file restored — this is separate from the DAP failure, but it can disturb reset/initialization and should not be left in place while you debug 1.

Important caveat: Error -1170 is a target-access failure. The fact that swapping one unit restored operation is consistent with a bad probe, but it is equally consistent with a reseated connector, a reset/power state, or a marginal JTAG link. The retrieved evidence does not establish a confirmed root cause for your specific boards, and nothing here identifies a known defect mode in the TMDSEMU110-U itself. Treating 5/17 as probe failures is not yet supported.

Recommended isolation sequence

Step 1 — Remove the configuration defect. Fix the CPU_RESET.gel path in your UniFlash/DSLite configuration. Then import the known-working CCS .ccxml into UniFlash; connection failures after XDS110 firmware updates have been resolved this way, and it guarantees probe mode, target voltage, SWD/JTAG selection, and TCLK match your working setup 2.

Step 2 — Apply the standard -1170 checks. Reset and power-cycle the target, verify configuration and JTAG connections, and retry at a lower TCLK. Note that lowering TCLK alone did not resolve one comparable external-XDS110 case, so do not stop there 3.

Step 3 — Cross-swap to prove where the fault lives. This is the decisive test given your volume:
- Put each of the 5 suspect probes on a board that programs successfully.
- Put the known-good probe on each of the 5 failing boards.

If failures follow the probe, it is the unit. If they follow the board, it is target-side.

Step 4 — If failures track the probes, investigate electrical over-stress. A comparable AM2432 case with repeated probe failures implicated EOS rather than software — specifically hot-plugging power and connectors, grounding, and inadequate ESD protection 4. In a 17-station production flashing setup, a sequencing or grounding issue is a plausible mechanism for a cluster of failures. Confirm all units are powered and connected in a fixed, defined order.

Step 5 — If failures track the boards, check target power integrity. AM263x devices can fail from insufficient power-plane connections; a documented AM2634 case involved inadequate copper for the device's >2 A inrush current, producing voltage differentials and ringing transients 5.

Step 6 — Only after DAP access is restored, validate the image itself. Apparent connection problems can transition into memory-load errors caused by an invalid linker memory map, so verify the image, linker map, reset script, and flash-loader configuration independently 6. For reference, AM263x ROM QSPI boot requires a 3.3 V-class flash, Quad Output Fast Read opcode 0x6B, Single Fast Read opcode 0x0B, eight dummy cycles, default 3-byte addressing, and at least 4 MB capacity 7.

Can you share whether all 5 failing units produced the identical Error -1170 output, and the result of cross-swapping one suspect probe onto a board that programs successfully?

1. Uploaded session log screenshot
2. E2E: Updated XDS110 firmware with CCS 20.4.0 and now UniFlash doesn't work
3. E2E: TMDSEMU110-U with MMWAVEICBOOST — can't get past this error
4. E2E: TMDSEMU110-U debug probe Error -1170 with AM2432
5. AM263x Power Design Application Note (SDAA344)
6. E2E: Can connect to XDS110 from CCS but there are errors
7. AM263x QSPI Flash Boot Application Note (SPRAD50A)

Best Regards,

Zackary Fleenor