• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 38 subscribers
  • Views 3 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMDSEMU110-U: Support Required: XDS110 Debug Probe Parallel Programming Issue with TMS570LS043x Using CLI

AMOL CHAVAN
Prodigy 10 points

Part Number: TMDSEMU110-U
Other Parts Discussed in Thread: UNIFLASH

Dear TI Support Team,

Good Evening,

My name is Mr. Amol Chavan from Kyoritsu Electric India Pvt. Ltd., Pune, Maharashtra, India - 411057.

Our target device is the TMS570LS043x microcontroller. We are using the XDS110 Debug Probes to program the target devices individually as well as in parallel.

We are using CLI (Command Line Interface) commands through the Windows Command Prompt for the programming process.

When we program the target devices individually, one at a time, the programming process completes successfully without any issues.

However, when we perform parallel programming using multiple XDS110 Debug Probes simultaneously, we are experiencing intermittent programming failures. For example, when we attempt to program 6 target devices simultaneously, approximately 3 to 4 devices generate errors, and the programming process for those devices fails. The remaining devices may complete the programming successfully.

We would like to understand the possible cause of this issue and whether there are any specific configurations or limitations related to parallel programming using multiple XDS110 Debug Probes with TMS570LS043x target devices through CLI commands.

Could you please provide your technical guidance on the following points:

  1. Is parallel programming of multiple TMS570LS043x target devices using multiple XDS110 Debug Probes supported?

  2. Are there any limitations when operating multiple XDS110 Debug Probes simultaneously on the same PC?

  3. Is any specific configuration required to uniquely identify and assign each XDS110 Debug Probe to its corresponding target device when using CLI commands?

  4. Are there any recommended USB configurations, such as using separate USB ports or USB hubs, when connecting multiple XDS110 Debug Probes?

  5. Are there any recommended JTAG configuration or signal integrity considerations when programming multiple devices simultaneously?

  6. Is there any specific CLI command-line option or configuration required for reliable parallel programming?

  7. Could the issue be related to simultaneous access or resource conflicts between multiple XDS110 Debug Probes running in parallel?

We can provide the exact CLI commands, programming scripts, error logs, and error messages generated during the failed programming attempts if required.

CLI Command: "C:\ti\uniflash_9.6.0\deskdb\content\TICloudAgent\win\ccs_base\DebugServer\bin\DSLite.exe" flash -e -v -t 30 -c "D:\TMS570_PRODUCTION_PROGRAMMER\ccxml\TMS570_XDS00006.ccxml" -f "D:\TMS570_PRODUCTION_PROGRAMMER\firmware\18133586.hex" "D:\TMS570_PRODUCTION_PROGRAMMER\firmware\Manufacting Data Endurance 2 channel CCP 10-11-23.hex" > "D:\TMS570_PRODUCTION_PROGRAMMER\logs\Board6.log" 2>&1

We would appreciate your technical guidance in identifying and resolving this issue.

 

Thanks & Regards,

Mr. Amol Chavan

Mo. +91 9561337754

E-mail: amol@kyoritsuelectric.com

Board1.log Board2.log Board3.log Board4.log Board5.log Board6.log 

  • 0
    TI__Mastermind 34963 points
    Hi Amol,
    Thank you for the detailed description and for including your exact DSLite CLI command — that's very helpful. Let me address each of your points:
    1. Is parallel programming of multiple TMS570LS043x devices using multiple XDS110 probes supported? Yes, running multiple independent XDS110 probes in parallel — each with its own DSLite process and its own .ccxml, targeting a separate device — is a supported production-programming approach and is commonly used by TI customers for volume manufacturing. However, TI does not officially validate a specific "N probes in parallel" throughput number; reliability at higher parallel counts (5–6+) is heavily dependent on host PC resources (USB, CPU, driver stack) rather than a hard firmware limitation in the XDS110 itself.
    2. Limitations of running multiple XDS110 probes simultaneously on one PC The most common limitations are:
    • USB host controller/bandwidth sharing – If multiple XDS110 probes share the same USB root hub/controller, the host can throttle or occasionally drop transactions under simultaneous heavy load, causing intermittent flash/verify failures.
    • Windows USB enumeration timing – When several probes initialize almost simultaneously (as happens when 6 DSLite instances launch in parallel), driver enumeration or COM/WinUSB handle assignment can occasionally collide, especially with older XDS110 firmware or driver versions.
    • CPU/process scheduling – Six simultaneous DSLite.exe processes compete for CPU time; if the host is under-provisioned, timing-sensitive JTAG operations (e.g., erase/program handshakes) can be delayed enough to trigger a timeout.
    3. Configuration needed to uniquely identify/assign each XDS110 to its target device Yes — this is essential. Each .ccxml must reference the unique serial number of the intended XDS110 probe (not just "auto-detect first available probe"). This is configured in the CCXML file's debug-probe connection properties (Serial Number field). Since your setup already uses separate .ccxml files per board (e.g., TMS570_XDS00006.ccxml), please confirm each file explicitly pins the correct probe serial number — if any are left on "auto" detection, two DSLite instances launched at nearly the same time could momentarily contend for the same probe or pick up the wrong one.

    4. Recommended USB configuration (separate ports/hubs)
    • Use separate USB root hub controllers where possible rather than a single hub feeding all 6 probes — motherboards typically have 2–4 independent host controllers; spreading probes across them reduces bandwidth contention.
    • Avoid low-quality/unpowered USB hubs. If a powered hub must be used, ensure it supplies full-rated current per port; XDS110 probes and target boards can draw enough current that marginal hubs cause brown-outs during flash erase (a common cause of intermittent failures).
    • Use short, good-quality USB cables — avoid daisy-chained hubs.
    5. JTAG/signal integrity considerations for simultaneous programming
    • Keep JTAG cable lengths as short as practical and avoid running them near noisy power lines, since simultaneous programming activity on adjacent boards can increase EMI coupling.
    • If you're seeing errors like "unable to access DAP" or scan-path/verification failures, consider lowering the JTAG clock (TCLK) in the ccxml for more margin, at the cost of some programming speed.
    • Ensure each target board has clean, adequately decoupled power — voltage droop during simultaneous flash-erase current spikes across 6 boards can cause verify failures on some units while others succeed (classic symptom of a shared/marginal power supply rail).
    6. CLI/DSLite options for reliable parallel programming
    • Increase the timeout margin (-t) if borderline timing failures occur.
    • Consider adding a small launch stagger (e.g., 1–2 second delay) between starting each DSLite instance in your batch script, rather than launching all 6 simultaneously — this avoids simultaneous USB enumeration/driver-handle contention at the OS level, which is one of the most common causes of exactly this "3–4 out of 6 fail intermittently" symptom.
    • Make sure all 6 .ccxml files pin explicit, unique probe serial numbers (see point 3).
    • Update to the latest XDS110 firmware and CCS/Uniflash version — probe firmware and USCIF/driver stack updates have historically improved concurrent-probe robustness.
    7. Could this be a resource/access conflict between probes running in parallel? Yes, this is the most likely root cause given your symptom pattern (intermittent, variable which boards fail, works fine individually). Likely contributors, in order of probability:
    1. USB enumeration/driver handle contention from simultaneous launch of 6 processes.
    2. Shared USB hub bandwidth/power limitations.
    3. Ccxml probe-serial-number binding not being explicit for all 6 configs.
    4. Host PC power-supply droop on target boards during simultaneous erase cycles.
    Recommended next troubleshooting steps:
    1. Confirm each .ccxml has an explicit XDS110 serial number.
    2. Distribute the 6 probes across multiple separate USB host controllers/hubs (not one hub).
    3. Add a short stagger between launching each DSLite CLI call instead of firing all at once.
    4. Share the failing Board*.log files — the exact error codes (e.g., -1170, -615, timeout codes) will let us pinpoint whether it's a JTAG connection issue, a verify/flash timeout, or a USB communication drop.
    5. Confirm XDS110 firmware version across all 6 probes is current and identical.
    Best Regards,
    Zackary Fleenor