[参考译文] 由于 OSX 上的固件更新而使 XDS220错误；正在尝试恢复

admin

Other Parts Discussed in Thread: AM1802

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1223092/bricked-xds220-due-to-firmware-update-on-osx-trying-to-recover

主题中讨论的其他器件：AM1802

我有一个 XDS220 (PN 516300-0001、串行 X2D_1401037)、我通过尝试在 OSX 上执行固件更新而成功锁定。此主题中所示的症状相同、但我似乎无法让 CCS (在 Linux 或 Windows 上)通过 XDS100v2与它连接。我已经连接(并验证) TDI、TDO、TMS、TCK、RTCK、 TRST、GND 和3.3V、但当我使用 CCS 测试连接时、系统提示检测到远端中断。如果我使用 OpenOCD、它实际上会进行连接、我可以停止/步进/等等处理器似乎不起作用、但将 fw1009.bin 加载到位置0x80010000并尝试在相同地址继续执行。

"看起来不工作"我的意思是处理器好像在运行、但我没有看到 USB 设备出现、如果我停止处理器、它似乎与我第一次连接时的无限循环指令相同。我也玩过 TCK 时钟速度、使用 RTCK 或忽略它… 似乎没有任何帮助。

> reset halt
JTAG tap: omapl138.jrc tap/device found: 0x1b7d102f (mfg: 0x017 (Texas Instruments), part: 0xb7d1, ver: 0x1)
JTAG tap: omapl138.etb enabled
JTAG tap: omapl138.arm enabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0xa00000df pc: 0x800016c8
MMU: disabled, D-Cache: disabled, I-Cache: disabled
NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.

> omapl138.arm curstate
halted

> reg
===== ARM registers
(0) r0 (/32): 0xa00000df (dirty)
(1) r1 (/32): 0xe1500001 (dirty)
(2) r2 (/32): 0xdafffffc (dirty)
(3) r3 (/32): 0xe59f0044 (dirty)
(4) r4 (/32): 0xe59f1044 (dirty)
(5) r5 (/32): 0xe2400c05 (dirty)
(6) r6 (/32): 0xe321f0d3 (dirty)
(7) r7 (/32): 0xe1a0d000 (dirty)
(8) r8 (/32): 0xe2400008 (dirty)
(9) r9 (/32): 0xe321f0df (dirty)
(10) r10 (/32): 0xe1a0d000 (dirty)
(11) r11 (/32): 0xe59f0054 (dirty)
(12) r12 (/32): 0xe59f1054 (dirty)
(13) sp_usr (/32): 0xe3a02000 (dirty)
(14) lr_usr (/32): 0xe4802004 (dirty)
(15) pc (/32): 0x800016c8 (dirty)
(16) r8_fiq (/32)
(17) r9_fiq (/32)
(18) r10_fiq (/32)
(19) r11_fiq (/32)
(20) r12_fiq (/32)
(21) sp_fiq (/32)
(22) lr_fiq (/32)
(23) sp_irq (/32)
(24) lr_irq (/32)
(25) sp_svc (/32)
(26) lr_svc (/32)
(27) sp_abt (/32)
(28) lr_abt (/32)
(29) sp_und (/32)
(30) lr_und (/32)
(31) cpsr (/32): 0xa00000df
(32) spsr_fiq (/32)
(33) spsr_irq (/32)
(34) spsr_svc (/32)
(35) spsr_abt (/32)
(36) spsr_und (/32)
(37) sp (/32)
(38) lr (/32)
===== EmbeddedICE registers
===== etm registers
===== etb registers

> load_image /home/andrew/ti/ccs1230/ccs/ccs_base/common/uscif/xds2xx/xds220_firload_image /home/andrew/ti/ccs1230/ccs/ccs_base/common/uscif/xds2xx/xds220_firmware_v1009.bin 0x80010000 bin
92814 bytes written at address 0x80010000
downloaded 92814 bytes in 2.201913s (41.164 KiB/s)

> mdw 0x80010000 0x20         
0x80010000: ea000004 40000000 4000033c 4000033c 40016a90 4004c3c8 e59f0098 e321f0db 
0x80010020: e1a0d000 e2400008 e321f0d7 e1a0d000 e2400008 e321f0d1 e1a0d000 e2400008 
0x80010040: e321f0d2 e1a0d000 e2400c05 e321f0d3 e1a0d000 e2400008 e321f0df e1a0d000 
0x80010060: e59f0054 e59f1054 e3a02000 e4802004 e1500001 dafffffc e59f0044 e59f1044 

> resume 0x80010000

... wait, nothing showing up on USB ...

> halt
target halted in ARM state due to debug-request, current mode: System
cpsr: 0xa00000df pc: 0x800015fc
MMU: disabled, D-Cache: disabled, I-Cache: disabled

> reg
===== ARM registers
(0) r0 (/32): 0xffffffff (dirty)
(1) r1 (/32): 0x00000004
(2) r2 (/32): 0xffffffff
(3) r3 (/32): 0xffffffff
(4) r4 (/32): 0x80000000
(5) r5 (/32): 0xe2400c05
(6) r6 (/32): 0xe321f0d3
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0xe2400008
(9) r9 (/32): 0xe321f0df
(10) r10 (/32): 0x80000aa0
(11) r11 (/32): 0x80003100
(12) r12 (/32): 0x00000001
(13) sp_usr (/32): 0x800030ec
(14) lr_usr (/32): 0x8000157c
(15) pc (/32): 0x800015fc (dirty)
(16) r8_fiq (/32)
(17) r9_fiq (/32)
(18) r10_fiq (/32)
(19) r11_fiq (/32)
(20) r12_fiq (/32)
(21) sp_fiq (/32)
(22) lr_fiq (/32)
(23) sp_irq (/32)
(24) lr_irq (/32)
(25) sp_svc (/32)
(26) lr_svc (/32)
(27) sp_abt (/32)
(28) lr_abt (/32)
(29) sp_und (/32)
(30) lr_und (/32)
(31) cpsr (/32): 0xa00000df
(32) spsr_fiq (/32)
(33) spsr_irq (/32)
(34) spsr_svc (/32)
(35) spsr_abt (/32)
(36) spsr_und (/32)
(37) sp (/32)
(38) lr (/32)
===== EmbeddedICE registers
===== etm registers
===== etb registers

我也尝试了分别手动设置 PC 和 SP 为0x80010018和0x40000000并恢复这种方式、但结果相同。

我非常确信、如果我只能通过 AM1802执行已加载的代码、我就能够恢复这种情况。我有两个问题：

1) 1)如何对 CCS 中的"SC_ERR_CTL_CBL_Break_far"(-183)错误进行故障排除/解决？网上没有太多的信息、有什么是通用的。我知道连接良好、因为 OpenOCD 可以与器件通信。

2) 2)我缺少什么使我无法通过 OpenOCD 完成所需的操作？

2 年多前

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Andrew、您好！

似乎是 XDS220是有问题的器件？ (与 AM1802不同？我对为何要讨论 AM1802并不十分清楚)

我将把您的问题提交给 CCS 团队进行评论。

此致、

Nick

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

Unknown 说：
1)如何对 CCS 中的"SC_ERR_CTL_CBL_break_far"(-183)错误进行故障排除/解决？网上没有太多的信息、有什么是通用的。我知道连接很好，因为 OpenOCD 可以与设备通信。

"电缆断开太远"错误表示器件之间以及调试探针连接到目标板上的 JTAG 接头时存在某种连接问题。

有关错误的更多详细信息、请参阅以下文档中"电缆断开"下的部分：

https://dev.ti.com/tirex/explore/node?node=A__ANoamrIZPWD2-6T-NDDWGg__ccs_devtools__FUz-xrs__LATEST

还可尝试其它建议、例如如上面文档中提到的降低 TCLK

Unknown 说：
2)我缺少什么是阻止我通过 OpenOCD 实现 AM1082所需的功能？

关于 OpenOCD 我建议不多。 Nick、可以帮助设计该器件吗？我假设目标器件是 AM1802。

谢谢

小标题

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Unknown 说：
似乎 XDS220设备出了此问题吗？ (与 AM1802不同？我对为何讨论 AM1802不十分清楚[/引述]
重新刷写板载 XDS200单元的固件：包含：

[报价]如果 XDS200单元的固件损坏、可使用与 XDS200设计中的 AM1802器件兼容的外部 XDS 调试探针重新刷写[/报价]

即、Andrew 可能是在砖型 XDS220中尝试通过使用不同调试探针连接至 AM1802来恢复 XDS220。

我假设隔离式探针 XDS220使用的 AM1802与未隔离的 XDS200相同。

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

我对不清楚表示歉意。

它是带砖的 XDS220。 XDS220在内部使用 AM1802。它是我已连接到 XDS100v2的卡边缘上的内部调试接口。我正在尝试使用 XDS100v2来通过 XDS220的内部卡边缘调试接口来解砖 XDS220。

CCS 抱怨我单击测试按钮时出现了"远端电缆断开"的情况、但是我已经验证并重新验证了 XDS100v2和 XDS220内部的卡边调试连接器之间的布线、我没有看到中断。我有 TDI、TDO、TMS、TCK、RTCK、 TRST、GND 和3.3V 接线、根据原始(闭合、锁定)线程、尝试了不同的 JTAG 时钟频率(100kHz 一直到10MHz、包括默认的"自适应高达1MHz")、但问题仍然存在。

如果我关闭 CCS 而改用 OpenOCD 来访问 XDS100v2、我可以直接连接到 XDS220的内部 AM1802。我可以看到使用 OpenOCD 的寄存器、转储器、控制代码执行。如果将 v1009二进制固件映像加载到0x80010000中、则可以看到加载的映像数据、并可以使用"resume 0x80010000"或将 IP/SR 设置为0x80010000/0x40000000并尝试恢复、但我看不到 XDS220在计算机的 USB 端口上显示、这是原始锁定线程中的视频所显示的内容。

我认为我遗漏了一些阻碍 CCS 验证 XDS100v2与 XDS220之间连接的因素、但关于此特定错误含义的信息很模糊、基本上是"检查布线"、我已经做过(以及重新做过和重新做过)。 OpenOCD 似乎没有问题、所以我确信电气接线是声音的。最好的猜测是 CCS 未能在幕后完成某个步骤。上传固件、发出硬件复位、将 IP 设置为0x8001000并告诉 XDS220的 AM1802处理器恢复似乎还不够、这就是我要在这里提问的原因。

是否必须执行任何特定的额外步骤才能使 AM1802在 XDS220内部执行我已加载到 RAM 中的固件？一些我不知道的 ICEPICK 或 CPU 状态？

否则、如何获取有关 CCS 为何对连接不满意的更多信息？如前所述、我可以确信 XDS100v2和 XDS220之间的电气连接是合理的、因为 OpenOCD 在与 ARM9通信时不会遇到问题。我可以手动运行`dbgjtag`命令，如果我不包含`-S integrity`选项，它将无错误地完成：

~/ti/ccs1230/ccs/ccs_base/common/uscif/dbgjtag -f ~/.ti/ccs1230/0/0/BrdDat/testBoard.dat -rv -o -F inform,logfile=yes -S pathlength 

-----[Print the board config pathname(s)]------------------------------------

/home/andrew/.ti/ccs1230/0/0/BrdDat/testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'libjioserdesusb.so'.
The library build date was 'Mar 10 2023'.
The library build time was '17:24:20'.
The library package version is '9.11.0.00128'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 64 32-bit words.

The JTAG IR instruction path-length was not recorded.

如果我添加`-S integrity`选项(这正是 CCS GUI 通过"Test"按钮执行的操作)、则我会收到相同的 SC_ERR_CTL_CBL_Break_far 错误：

$ ~/ti/ccs1230/ccs/ccs_base/common/uscif/dbgjtag -f ~/.ti/ccs1230/0/0/BrdDat/testBoard.dat -rv -o -F inform,logfile=yes -S pathlength -S integrity

-----[Print the board config pathname(s)]------------------------------------

/home/andrew/.ti/ccs1230/0/0/BrdDat/testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'libjioserdesusb.so'.
The library build date was 'Mar 10 2023'.
The library build time was '17:24:20'.
The library package version is '9.11.0.00128'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 64 32-bit words.

The JTAG IR instruction path-length was not recorded.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 64 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-183' (0xffffff49).
The title is 'SC_ERR_CTL_CBL_BREAK_FAR'.

The explanation is:
The controller has detected a cable break far-from itself.
The user must connect the cable/pod to the target.

遗憾的是、此工具未提供更多的调试信息、或者我可能不知道如何调用或解释此类信息。

出于完整性考虑、此处是 CCS 生成的 testBoard.dat 文件：

$ cat ~/.ti/ccs1230/0/0/BrdDat/testBoard.dat 
# config version=3.5
$ sepk
  pod_drvr=libjioserdesusb.so
  pod_port=0
$ /
$ product
  title="Texas Instruments XDS100v2 USB"
  alias=TI_XDS100v2_USB
  name=FTDI_FT2232
$ /
$ ftdi_ft2232
  usb_vid=0x0403
  usb_pid=0xa6d0
  gpio_l0="TRSTn,Active_Low"
  gpio_l1="EMU_Pin_Enable,Active_Low"
  gpio_l2="EMU_Pin_0,Active_Low"
  gpio_l3="Adaptive_Clock,Active_High"
  gpio_h0="SRSTn,Active_High"
  gpio_h1="SRSTn_In,Active_Low"
  gpio_h2="Power_Loss_Detect,Active_Low"
  gpio_h3="Power_Loss_Reset,Active_High"
  gpio_h4="EMU_Pin_1,Active_Low"
  gpio_h5="Cable_Disconnect,Active_High"
  gpio_h6="Loopback,Active_High"
$ /
$ uscif
  tdoedge=FALL
  jtagboot_mode=disable
  jtagboot_value=hiz
  powerboot_mode=disable
  powerboot_value=hiz
  tclk_program=ADAPTIVE
  tclk_frequency=4.0MHz
  loopback_mode=disable
  loopback_value=disable
$ /
@ icepick_c family=icepick_c irbits=6 drbits=1 subpaths=3 systemresetsupported=1 systemresetwhileconnected=1
  & subpath_2 address=19 default=no custom=no force=yes pseudo=no cancelreset=0x0
    @ etb11_0 family=etb11 irbits=4 drbits=1
  & subpath_1 address=18 default=no custom=no force=yes pseudo=no cancelreset=0x0
    @ arm9_0 family=arm9xx irbits=4 drbits=1
  & subpath_0 address=17 default=no custom=no force=yes pseudo=no cancelreset=0x0
    @ pru_1 family=pru irbits=0 drbits=0
    @ pru_0 family=pru irbits=0 drbits=0
  & /
# /

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Ki 您好、

我在我的原始文章中提到,我已经看了你链接的页面,但再次阅读它,我注意到这:

"远离自身的电缆断开"的另一个可能原因可能是 TVRef 信号(引脚5)被上拉至 IO 电压、或 TDIS (引脚4)被下拉至接地。 TVRef 应通过一个小限流电阻连接到 IO 电压。

"小值电阻器"的值到底应该是多少？可能是几百欧姆？我确实将其直接连接到 IO 电压(3.3V、XDS220内部调试卡边缘连接器上的引脚14)。它不是"上拉"的、而是直接连接的。我没有*没有* TDIS 连接到任何东西;我会按照 https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds_target_connection_guide.html 将此连接接地, 然后重试。

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Unknown 说：
CCS 投诉我单击测试按钮时出现了"远端电缆断裂"、但我已经验证并重新验证了 XDS100v2和 XDS220内的卡边调试连接器之间的布线、我看不到中断

您能尝试运行吗 /ccs/ccs_base/common/uscif/xds100serial 并查看在 OSX 下是否存在通用 FT2232串行转 USB 适配器？

通过 Linux 下的 CCS、我们发现、除非您按序列号指定了 XDS100v2、否则 CCS 可以使用通用的 FT2232串行转 USB 适配器、从而产生"控制器已检测到线缆断开、并且距离本身很远"。

有关示例、请参阅具有 C2000处理器和 XDS100v1的机器上的 Linux 64 OS。

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

没错,切斯特;我欺骗了我的 XDS220(不是一个 ISO 单元,只是来自 Spectrum Digital 的 XDS220,其网站不幸早已消失)。我的特定 XDS220探针的器件型号为516300-0001、该探头未进行隔离。

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Chester、

正确检测到 XDS100v2 (我以前确实有问题、但根据安装文档更新 udev 规则来修复)：

$ ~/ti/ccs1230/ccs/ccs_base/common/uscif/xds100serial 
Scanning for XDS100 emulators...

VID/PID    Type            Serial #    Description
0403/a6d0  XDS100v1/v2     SD05YSNA    Texas Instruments Inc.XDS100 Ver 2.

现在我几乎可以100%确定 CCS 的问题是因为我没有将引脚4 (TDIS)连接到任何部件。我将对其进行论证和报告。与一个小小的运气,你会听到我的成功/救济的百思妙想,只要你碰巧在世界上。：-)

0 admin 2 年多前

TI__Guru**** 2350830 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

XDS100v2引脚4未接地是 CCS"far break"错误的问题。我现在已经过去了该错误、能够成功恢复我的 XDS220。

有几个问题原始线程没有指定和/或没有明确说明：

TDI、TDO、TMS、TCK、RTCK、 TRST、GND 和3.3V 不够。 TDIS (XDS100v2 14引脚调试连接器上的引脚4)必须接地、否则将出现 "SC_ERR_CTL_CBL_Break_Far"错误(-183)。由于 OpenOCD 不关心这个无关信号、所以它不受影响。
加载到 RAM 的正确二进制文件是 xds200_firmware_v1009.bin 文件。不会 xds220_firmware_v1009.bin 或 xds220_firmware_iso_v1009.bin 文件。这既不符合直觉、也很令人困惑。您必须加载 xds200固件文件，而不是 xds220固件文件，即使您有 XDS220。

我怀疑如果我在 OpenOCD 中加载 XDS200固件文件会起作用、因为在 CCS 中加载任一 XDS220固件文件的结果与在 OpenOCD 中加载的结果相同。

$ ./xds2xx_conf get xds2xxu 0
boardRev=1
ipAddress=192.168.77.36
ipConfig=dhcp
ipGateway=0.0.0.0
ipNetmask=0.0.0.0
productClass=XDS2XX
productName=XDS220
serialNum=S200-000E9903975B
swRev=1.0.0.9
hostCPU=AM1802
emuCtrlType=Bit bang
extMemType=SDRAM
portUSB=true
portENET=true
portWIFI=false
portRS232=false
EnableUSBSerial=false
CurrentMeasure=true

最后一件我不知道的事情是、我拥有的 XDS220或许毕竟是 ISO 标准、尽管没有明确标记。这可能是更新脚本最初失败的原因。

对于子孙后代、我使用了以下步骤：

将 XDS100v2 (或任何其他所需的 JTAG 工具)连接到内部边缘连接器。我使用了 Samtec HSEC8-110-01-L-DV 连接器、因为我不想焊接到电路板上。
TDI、TDO、TMS、TCK、RTCK、必须连接 TRST、GND 和3.3V。此外、如果使用 CCS、则"目标断开"信号(TI 14引脚调试连接器上的引脚4)必须接地、否则会出现"远端断开"错误。
如果使用 OpenOCD、您可以使用 BeagleBone 目标定义、因为它也使用 AM1802。
连接到目标、从0x80010000处将 xds200_firmware_v1009.bin 加载到 RAM。 请注意、这是 XDS200文件、而不是 XDS220或 XDS220-ISO 文件。它们不起作用。您必须使用 XDS200文件。
复位 ARM9、将 PC 设置为0x80010000或从0x80010000处继续执行。如果一切顺利、XDS220复合 USB 设备将显示在您的 USB 设备列表中。
使用 xds2xx_conf 程序将固件更新至 XDS220或 XDS220_ISO 固件。
使用 xds2xx_conf 程序重新引导 XDS220。这需要一分钟时间、但 USB 器件应在之后再次显示。
使用 xds2xx_conf 程序对 CPLD 文件进行编程。这也需要一分钟左右的时间。
使用 xds2xx_conf 程序重新启动 XDS220。现在应该对其进行了更新并能正常工作。

另一个小注意事项是、xds2xx_conf 实用程序看起来像是从固件文件所在的目录下运行。通过指定完整路径更新固件没问题、但对 CPLD 文件进行编程会发出一个奇数的"文件 app_cpld.bin 不存在"错误。我从不指定该名称、而是用完整路径指定了 xds220_CPLD _ISO_v1009.xvsf 文件。重新启动 XDS220并从 μ~/ti/ccs1230/ccs/ccs_base/common/uscif/xds2xx 目录运行脚本可以解决问题、但这并不直观。

XDS220上的边缘连接器与 XDS100v2上的 TI 14引脚连接器之间的具体互连如下：

信号名称	XDS220边缘	XDS100v2插头
TRST	1.	2.
TMS	3.	1.
TDI	5.	3.
TDO	7.	7.
GND	11.	8,10,12.
RTCK	13.	9.
TCK	15.	11.
3.3V	14.	5.
TDIS	-	4 (接地)

Code Composer Studio™︎（参考译文帖）

Code Composer Studio™︎（参考译文帖）(Read Only)

[参考译文] 由于 OSX 上的固件更新而使 XDS220错误；正在尝试恢复