Other Parts Discussed in Thread: CODECOMPOSER
We’ve confirmed our board is functional because we have pre-existing code downloading via HPI that runs and works as-intended.
We’ve confirmed the Spectrum Digital XDS200 debug pod is functional because we tested it against a BeagleBone.
We’ve confirmed that the Spectrum Digital XDS200 debug pod is loaded with the latest 1.0.0.8 firmware.
We’ve confirmed the JTAG signal integrity between the pod and the DSP using an oscilloscope.
We’ve confirmed that our JTAG circuitry matches the TI reference designs we can find, where the various designs aren’t contradictory.
We’re using the latest version of CodeComposer Studio supported by our DSP (v5.5.0).
We’ve tried using a Win7 computer and a separate Win10 computer.
Our steps to reproduce are:
- Connect XDS200 USB debug pod to host computer
- With power OFF, connect XDS200 pod to target system
- Create a new Target Configuration in CCS
- Set the Connection to “Texas Instruments XDS2xx USB Debug Probe”
- Set the Board or Device to “TMS320C5410A.”
- Apply power to the target system
- Press the “Test Connection” button in CCS.
We observe on the oscilloscope that nTRST is driven low for a duration of roughly 600usec. During that time, just after nTRST is driven low, there are 100 TCK cycles. Then TCK doesn't toggle for about 520 usec. Then TCK toggles for another 10 cycles. Then nTRST is driven high.
We never see any change on TDI or TDO.
CodeComposer then reports a -233 error that the IR and DR registers cannot circulate bits and that the scan-path appears to be stuck-at-ones or stuck-at-zeroes.
We’ve confirmed that we do not have a low-resistance connection between either TDI or TDO and ground or Vcc.
Everything appears to be configured properly, cleanly driven, and functioning as-intended, but we’ve never been able to establish a connection between CCS and the DSP.
With clean signals, known-good target systems, and known-good debug pods, where else might we look for JTAG communications problems?