[参考译文] MSP432E401Y：将 MSP432E401Y 用作 XDS110

我假设在刷写引导加载程序二进制文件后、您要连接到 Launchpad 上的 micro-USB 端口 U7以便与 MSP432E401Y 通信。 是这样吗？ 我认为这不会起作用。  

这是我们尝试使用的方法之一。 我们检查了 C2000控制卡 XDS (MSP432)和 MSP432E401Y LaunchPad 的原理图、看起来 USB 端口实际上连接到了相同的引脚、 这告诉我们、他们应该都能够像我们在控制卡上工作一样使用 XDSDFU？

我们还需要尝试其他什么吗？ 尝试通过 UniFlash 通过 JTAG 加载引导加载程序/固件也未成功。

我们检查了 C2000控制卡 XDS (即 MSP432)和 MSP432E401Y LaunchPad 的原理图，看起来 USB 端口实际上连接到了相同的引脚， 这告诉我们他们应该能够像我们在控制卡上工作一样使用 XDSDFU 吗?

我假设您指的是 F280039C controlCARD 的 J1：A、该端口可配置为提供 XDS110仿真和 USB 转 UART 通信。 我对 LaunchPad 的硬件细节了解不多、需要与工程部门联系以获得更多详细信息。

是的、正确。

为了澄清这一点、我们在此阶段的主要目标是能够 插入 LaunchPad 的 micro-USB 端口(U7)、并让 XDSDFU 实用程序在我们执行"xdsdfu -e"命令时将目标 MSP432E401Y (U1)器件识别为 XDS 器件(固件版本正确)。  

上一条评论的意思是、我们可以使用 F280039C 控制卡的 J1：A USB-C 连接器来更新 MSP432E401Y (U1：A)器件的固件、您的建议应该有效。 由此、我们假设应该可以为 LaunchPad 执行类似的操作、因为根据原理图、连接看起来是相同的。

最后一条评论的意思是，我们可以使用 F280039C 控制卡的 J1：A USB-C 连接器来更新 MSP432E401Y (U1：A)器件的固件，这是您建议的工作方式。 由此、我们假设应该可以为 LaunchPad 执行类似的操作、因为根据原理图、连接看起来是相同的。

我会提请器件专家注意该主题、以确认上述情况。

哦、我还应该提到、我们已经能够让 Windows 设备管理器通过在启动时将 JTAG (J101) TDO 引脚接地来识别 LaunchPad MSP432E401Y 器件、而"xdsdfu -e"确实会在 DFU 模式下将该器件识别为1 (序列号为所有零)。

但是、当我们尝试使用 XD1SDFU 将 XDS 引导加载程序或 XDS 固件上传到器件时、该过程会失败、通常会出现未知错误(-4)。 在其他情况下、XDSDFU 据认为能够成功上传固件(从不是引导加载程序)、但随后完全无法在 LaunchPad 上检测到目标 MSP432E401Y (在 DFU 模式下或作为 XDS 模式下)。

工程部门创建了一个定制的 xdsdfu 实用程序、它可以通过附加的"-t"选项打印出附加的诊断、请尝试一下、并在您遇到困难时提供附加的诊断信息：

e2e.ti.com/.../xdsdfu.zip

感谢您提供新的升级实用程序。 遗憾的是、我们无法使用它进行固件更新、尽管我们确实收到了一些可能有用的错误代码。

一般而言、我们首先使用 UniFlash/JTAG 从已知 XDS110 (TM4C129)擦除 LaunchPad MSP432E401Y (U1：A)、以获得一个已知空白的起点、 然后、使用您提供的启用了"-t"标志的新 XDSDFU 实用程序上传了原始 XDSDFU 下载随附的固件和引导加载程序(固件版本3.0.0.25、未列出引导加载程序版本、但应该是最后修改版本3/23)。

在这两种情况下、我们首先得到一个与此类似的标头：

LMDFUDeviceOpen 0
从0x000000000014FC78下载8个字节
完成空闲时的状态、STATUS_OK 状态
LMDFUDeviceParamsGet 0x0000000000613580
从0x000000000014FCA0下载8个字节
完成空闲时的状态、STATUS_OK 状态
正在将.\firmware_3.0.0.25.bin 下载到设备...
LMDFUDeviceIsValidImage 0x0000000000613580 0x0000000000645FA0 315357
映像未完全 DFU 包装。 下载为二进制文件
正在将映像下载到闪存... LMDFUDownloadBin 0x0000000000613580 0x0000000000645FA0 315357验证
从0x000000000014FC18下载8个字节
完成时的状态 DNLOAD_IDLE、状态 STATUS_OK
从0x0000000000645FA0下载1024个字节

然后、下列行的多个输出：

完成时的状态 DNLOAD_IDLE、状态 STATUS_OK
从0x0000000000645FA0下载1024个字节

最后还有一条错误消息：

已完成。
LMDFUDeviceClose 0x0000000000613580
从0x000000000014FCC0下载8个字节
Endpoint0Transfer 错误6

当我们尝试上传固件时、器件仍处于 DFU 模式、但在对引导加载程序执行此操作后、在运行"$ xdsdfu -e"时未找到器件。 希望这对您有所帮助。

嗨、Ki！ David 来自 Ethan 所在的同一家公司、我将负责帮您写下有关我们尝试过的不同方面的一些评论。

我只是想对上述注释做一点更明确的说明(我们再次阅读、在某些地方会有些含糊不清)、并提供了我们使用的步骤/命令的更具体的列表：

1. 使用基于 TM4C129的 XDS110上通过 JTAG 的 UniFlash 擦除目标 MSP432E401Y
2. 拔下连接到 TM4C 和 JTAG 跳线的 USB 电缆
3. 将 MSP432E401Y 侧的 JTAG TDO 引脚接地、然后将 USB 电缆插入 LaunchPad 的该端
4. 在 XDSDFU 中、运行"$ xdsdfu -e"以验证器件是否确实在 DFU 模式下显示
5. 分别通过"$ xdsdfu /b boot_loader.bin -r -v -t"和"$ xdsdfu -f firmware_3.0.0.25.bin -r -t"上传引导加载程序/固件
6. 运行"$ xdsdfu -e"以检查并查看目标 MSP432E401Y 器件的新状态

如前所述、我们本来希望能够尝试通过 XDSDFU 上传引导加载程序和固件、但在上传引导加载程序后、实用程序无法识别器件、这大概是由于单个将每个文件上传到空白器件时遇到的错误(6)。

我在我的 launchpad 上尝试了阶梯。 一些评论：

除了下面的#2，我按照您所做的步骤#1-4执行操作：

对于2号、我拔下 J101上与 JTAG 相关的跳线、并仅保留3.3V、5V 和 GND。 然后我重新插入 USB 电缆来供电。 请注意、USB 电缆不是插入到 PC 上、而是插入到单独的电源上。 您是如何通过 JTAG 侧的 USB 连接而不是为的板供电的。

对于#5： 通过 xdsdfu 刷写引导加载程序二进制文件后、出现"USB device not recognized"错误、xdsdfu 不再检测到任何设备。 这听起来就像发生在你身上的事情：

如前所述，我们希望能够尝试通过 XDSDFU 上传引导加载程序和固件，但实用程序在上传引导加载程序后无法识别该器件

看起来我可以重现问题。 我会看一下我是否可以让工程师更仔细地了解我的环境

在步骤2之前、我们已通过 USB101端口将 LaunchPad 以及 GND、5V、3.3V 和 JTAG (TMS、 TCK、TDO、TDI)跳线已安装。 这是我们用于擦除目标 MSP432E401Y 器件并检查其是否为空白的配置。

之后、我们通过 U7 USB 端口插入 LaunchPad、并移除 JTAG 跳线、保持 GND、5V 和3.3V 的跳线与消隐过程中相同(否则、目标 MSP432E401Y 似乎无法接收3.3V 电源)。 这是我们用于尝试刷写引导加载程序/固件的配置、同时使用 PC 通过 U7 USB 端口传输的电源和数据。

在这两种配置中、我们保留安装了所有中间的跳线 JP2、JP4、JP5、JP6和 JP7； 对于5V 电源跳线 J1、我们保持安装了5V-OTG 和5V-XDS、但未连接5V-EXT 的引脚。

是的、这与我的设置类似。

我一直在与一名 CCS 工程师探讨此问题。 使用 CCS 单步执行刷写的引导加载程序时、我们可以看到一切都正常、直到在 USB 配置期间设置到以下行：

越过这一点将导致程序进入杂草中。 我们觉得尝试使用 Launchpad 上的 USB 端口存在一些问题、但目前缺少进一步的详细信息。

啊,很高兴听到我们发现了问题的根源! 最幸运的是,明白了,我们将焦虑地等待解决方案。

更多详细信息：

出现问题的确切位置如下面突出显示的汇编指令中所示、位于地址(0x20001190)处。

这发生在 USBBLInit ()函数中、该函数(根据注释)用于初始化引导加载程序 USB 函数并将 DFU 器件置于 USB 总线上。 单步执行该 asm 指令时、主机似乎失去与之前检测到的已连接 MSP432E 器件的连接。

我还是觉得根本原因是 Launchpad 上的 USB 端口接线的方式。 可能有某种情况会阻止此信号按预期工作。

请注意、调试 Launchpad 上的 USB 端口超出了软件工具团队的专业知识。  能否提供更多信息。 为了正确设定期望、我预计不会对此快速解决。

谢谢

小

感谢您深入了解下一级-它为我提供了一条潜在的线索、提示我了解 F28003x controlCARD (在 MSP432E401Y 上运行 XDS110固件)的一些原理图。

在 F28003x 控制卡上、MSPE401Y 上有一个数字输入引脚、该引脚似乎由 PC 的 USB 连接驱动(下图)。 由于 MSP432E401Y 数据表5.15.9指出"除 PB1 (USB0VBUS)外、所有 GPIO 信号均可耐受3.3V 电压、因此该引脚似乎具有特殊用途。" 并且"PB1用于 USB0VBUS 信号、需要5V 输入。"

TI 团队是否知道需要连接 MSP-EXP432E401Y LaunchPad 上的这个 USB 用途引脚(或任何其他引脚)以使其与`xdsdfu`实用程序和/或 XDS110固件兼容？

USB0VBUS 信号和5V 要求的第二个问题是：USB 标准或 MSP432E401Y USB 外设要求电压是5V？

换句话说、如果由3.3V 信号驱动、MSP432E401Y 是否能够识别主机已连接/断开的状态？

我缺乏解答这些特定硬件问题的专业知识。 我会将该主题提请器件专家注意、  

USB0VBUS 信号和5V 要求的第二个问题是：USB 标准或 MSP432E401Y USB 外设要求电压是5V？

[/报价]

按照标准、它必须是5V 输入。 PB1用于 USB0VBUS。  此信号用于会话请求协议。 此信号允许 USB PHY 既可以
感测 VBUS 的电压电平、并在 VBUS 脉冲期间暂时上拉 VBUS。 当 PB1用于 USB0VBUS 功能时、它必须是5V 输入。 如果施加3.3V 电压、则它可能不符合输入引脚的 VIH。  

这是关于 PB1的另一条注意事项。 请参阅 MSP432E 系统设计指南的第4.3.1节。  https://www.ti.com/lit/pdf/slaa770

我们即将在截止日期前订购具有 MSP432E401Y 的电路板、我们想将其用作 XDS110、并想检查刷写这些芯片时遇到的问题。 问题来源是否有任何更新？  

由于我们可以使用 XDSDFU、而对于用作  C28003xC controlCARD 的 XDS110的 MSP432E401Y、没有问题、因此我们认为该问题可能与那里的实现与 MSP432E401Y LaunchPad 上的内部接线之间存在的一些差异有关 (与某些软件错误相反、尽管这肯定也是可能的)。 每个原理图中是否有一些特定部分值得深入探究、以查看是否存在差异？

我们进一步询问了 引脚96 (PB1)是否连接到5V、但似乎已经在 LaunchPad 和 controlCARD 上进行了此连接。

由于我们能够在用作  C28003xC controlCARD 的 XDS110的 MSP432E401Y 上使用 XDSDFU 而没有问题，因此我们认为该问题可能与那里的实现与 MSP432E401Y LaunchPad 上的内部布线存在一些差异有关 (与某些软件错误相反，尽管这也肯定是可能的)。

我同意这一点。 MSP432E401Y 是一款已知支持的 XDS110实现器件、许多现有设计会使用该器件(例如您提到的 controlCARD)。  

每个原理图中是否有一些特定部分值得深入研究，以了解是否存在差异？

同样、本部分超出了我的专业领域。 我愿意听从 Charles 或设备/硬件团队的任何人的意见。

我们(维护 XDS110固件的软件团队)可以说、MSP432E401Y 支持 XDS110实现、 我们无法官方支持尝试重新使用现有 MSP432E401Y LaunchPad 来模拟 XDS110调试探针。  

我们想给这条线一些凸起、因为我们在最后仍然会撞到这里。

我们已经确定 PB1 USB0VBUS 引脚确实已连接到 LaunchPad 和 controlCARD 上的5V ...硬件团队是否对如何以不同的方式连接两个开发套件上的器件有任何其他想法？

尊敬的 David：

 我仅支持 TM4C MCU。 我真的不能代表 C2000 controlCARD。  

感谢更新、Charles、我们在结束时会继续查看、但请告诉我们您是否认为两种实现方式之间有任何不同之处。 但有一个问题：您是否有任何理由认为这可能会导致根据之前进行的调试工作通过 USB 与已连接的 MSP432E MCU 器件断开连接？ 或者、或许我们应该联系其他人、以便他们对该问题有更深入的了解？

关于这一点: Ki,你是否有任何见解,什么类型的事情可能导致连接丢失,特别是在该指令? 这可能是功率损耗/不稳定问题、还是我们应该更多地关注数据方面的问题？

尊敬的 David：

我不想在这个问题上有更多的东西。 抱歉。

小

我是否还可以与其他人就这方面进行联系？ 如果论坛不适合这样一个特定的话题,也很乐意发送电子邮件。

是否有其他人可以就此联系？

我不是。 器件专家知道该主题、因此如果他们有任何进一步的注释、他们可以回复该主题。