[参考译文] MSP-FET：从1.4a 迁移到2.0+ MSP-FET

您好 Stefan、

很抱歉、我不理解您的问题。

您在使用 MSP-FET 时遇到下载问题？ -a、-n 标志意味着什么？

谢谢！

此致

Johnson

您好 Stefan、

收到您的反馈后 、我将与 MSP-FET 专家联系、以检查是否存在此问题。

另一个问题：

您如何查看 MSP-FET 的硬件版本？

谢谢！

此致

Johnson

很抱歉耽误你的回答。

我有列出型号的设备随附的原始包装箱。

它似乎仅在尝试读取时复位。 这仅使用 SBW 而不是 JTAG。 我在多个不同的 MSP430开发板上获得相同的行为、因此它不是隔离的。

您好 Stefan、

您是否已将 MSP430Flasher 更新为最新版本进行测试？

 软件和硬件之间可能存在一些兼容问题。
这种异常复位会影响您的应用？

也许您也可以尝试使用 Uniflash 工具进行下载、这是最新的烧录工具。

谢谢！

此致

Johnson

是的、最新版本中的所有内容。

如果器件复位、代码也会复位、这会不幸地影响操作。

我将尝试使用 Uniflash 工具、但在命令行中是否有方法使用此工具？ 我需要能够自动进行编程。

您好 Stefan、

Uniflash 支持命令行。

谢谢！

此致

Johnson

最后安装了 Uniflash 并尝试使用命令行。 我能够进行闪存和技术读取、但我确实需要导出的文件能够以 ti-txt 格式读取、就像我正在加载的文件一样。 是否有方法转换数据？ 我只看到二进制和 COFF 的选项。

您好 Stefan、

请下载最新版本 uniflash、这样就可以导出 TI-TXT 格式：

https://www.ti.com/tool/UNIFLASH?keyMatch=&tisearch=search-everything&usecase=software#downloads

谢谢！

此致

Johnson

好的。 只是为了澄清和更新。

我将 Uniflash 6.4与 MSP-FET 1.4a 和2.0+搭配使用。 此芯片为 MSP430FR5739、插座板为 MSP-TS430RHA40A。 所有跳线均处于 SBW 的正确模式。

我能够使用 Uniflash GUI 和脚本上的所有内容。

我所说的是、对于 dslite GUI 存储器模式、没有 ti-txt 输出选项。 不过、我确实编写了自己的 python 脚本、以将.bin 数据转换为类似的格式、但我认为缺少该选项是一个很大的疏忽、因为它应该替换具有该选项的 MSP430Flasher。

真正的问题是、无论 Uniflash GUI、脚本或 MSP430Flasher.exe 如何、MSP-FET 2.0+都会导致每次我使用 SBW (两线制 JTAG)读取时器件复位。 MSP-FET 1.4a 上完全相同的脚本和步骤不会导致此问题。 如果2.0应该更好、为什么它会导致此问题？

同样、这种情况发生在多个电路板和芯片上、具有多个编程器、多台计算机上、所有器件都运行最新的软件和驱动程序、因此这不是由有缺陷的电路板或编程器造成的。

编辑：

不确定这是不是原因、但我在 VCC (来自 MSP-FET 的 VCC_TOOL)、TCK 和 TDI/TDO 上放置了一个示波器、并且信号之间的差异似乎是  、在每次读取 MSP-FET 2.0+之前、TCK 和 VCC 上的电压短暂下降至大约0.3V、 但不会出现在 MSP-FET 1.4a 上。

我的假设是、这足以对器件进行下电上电、但我还运行了外部3.3V 以确保没有下电上电、并观察到相同的复位行为和 TCK 压降。

TCK 上的这个短暂压降会导致这个复位吗？ 如果是、为什么 MSP-FET2.0会发生这种情况？ 由于 VCC_TOOL 电压下降、MSP-FET 侧显然有一些短暂的功率下降。

遗憾的是、我目前无法布置示波器波形、但这应该能够复制到您的一侧。

更新：我进行了一些研究来确定常规行为、结果如下：

MSP-FET 1.4a 外部电源：无复位

MSP-FET 1.4a 内部电源：无复位

MSP-FET 2.0+外部电源：无复位

MSP-FET 2.0+内部电源：复位

我之前还注意到、MSP-FET 2.0+ int 上的电源在读取前循环、因此我90%的人确信这就是它复位的原因。

然而、这并未解释整个情况、因此我去掉了 MSP-FET 和  MSP-TS430RHA40A 之间的带状电缆、并用 Dupont 连接器替换了标准单根导线、以便进行调试。

然后、我通过线缆将其移除、直到行为发生变化。 经过大量试错后、我发现 TEST/VPP 引脚8在移除后导致两个器件的外部和内部电源均复位。

利用这一发现、我将示波器连接到 TEST/VPP 引脚8、TDO/TDI 引脚1和 TCK 引脚7、并在 TEST/VPP 引脚8连接和断开的情况下观察到上述行为。 结果如下：

具有测试功能的 MSP-FET 1.4a 外部电源：无复位

不带测试功能的 MSP-FET 1.4a 外部电源：复位

具有测试功能的 MSP-FET 1.4a 内部电源：无复位

不带测试功能的 MSP-FET 1.4a 内部电源：复位

具有测试功能的 MSP-FET 2.0+外部电源：无复位

不带测试功能的 MSP-FET 2.0+外部电源：复位

具有测试功能的 MSP-FET 2.0+内部电源：复位

不带测试功能的 MSP-FET 2.0+内部电源：复位

在示波器上、对于 ext 和 int w/ test、TCK 引脚7信号在模式中有奇怪的"阶跃"、而不存在 w/o test。

然而、这些"步骤"确实与 来自 MSP-FET 的 TEST/VPP 引脚8上的信号完全相对应、并且当信号为低电平时、电压被拉低、充当分压器。

然后、我在具有多个不同器件的多台计算机上重复此操作、同时具有两种类型的多个 MSP-FET、并反复得到相同的结果。

结论：

TCK/VPP 引脚8上有一个信号、该信号对 TCK 引脚7执行一些奇怪的操作、这会导致它不复位(我所需的结果)、如果不存在、它会在读取时复位。

虽然这种"技术上"的做法可以"解决"这个问题，但这提出了更多需要解决的问题和关切。

如果根据文档、TEST/VPP 用于安全保险丝烧断、为什么我在没有设置该选项时看到此信号、它会导致器件不复位？

2.为什么文档中有关此信号以及这些产品的行为完全错误。

3.为什么在内部电源上、MSP-FET 2.0+会在读取前下降？ 这是完全不可接受的！

4、为什么没有人能想到这一点呢？

我还没有尝试跟踪操作、 但通过查看 MSPFlasher_1.3.20源代码、我看不到 任何对 MSP430_Configure (interface_mode)的调用、我认为这意味着 MSP-FET 将使用 automatic_if 留在 MSP-FET 中、这可能会驱动 TEST/VPP、这是在4线制 JTAG/2线制 SBW 之间自动选择的一部分。

某些具有多路复用 JTAG 引脚的4线制 JTAG 器件需要 TEST 引脚。

也许将 MSPFlasher 源代码修改为添加一个控制接口选择的选项会有所帮助。

理论上、PC 中 MSP430 DLL 的所有源代码和 MSP-FET 中的固件都是开源的且可用。

我不知道代码是打开的。 我将需要查看是否有永久的方法来修复此问题、而不需要更改硬件。

我要问的两个主要问题仍然是：

该"步进"信号使器件不会复位。 或者更好的问题是、TCK 信号到底是什么导致器件复位？

2.为什么 MSP-FET 2.0+ int 电源在读取前突然重启？

这两个问题可能都存在于代码中的某个位置。 我将尝试寻找来源、但这远远超出了我有限的编码知识、因此可能需要具有更多经验的人来找到答案。

只需从目标器件(FR5739)侧清除数据即可。 对于目标器件上的 SBW 接口、只使用测试(SBW_TCK)和复位(SBW_TDIO)引脚(具有连接的接地)以及来自目标方或主器件侧的 VCC。 VCC 通过 FET 输出端为电压转换器的一侧供电(14引脚连接器)。

对于 MSP-FET 主站和 FRAM 目标方之间的 SBW 接口、使用 FET 14引脚连接器上的引脚1、2或4、7和9。 FET 14引脚连接器上的其他引脚(包括引脚8 TEST/VPP)应断开连接。 这是 slau278 (MSP430硬件工具用户指南)中的图2.3。

感谢您提供信息。

我完全理解用户指南中的"目标"设置。

简单地说，用"预期"的方式来挂接不起作用。 它会在读取时导致器件复位。

在所有开发板上向引脚7 TCK 添加引脚8测试跳线、工作正常、读取时不会复位器件、因为我理解的是测试时的意外信号。

我认为这就是为什么不能更早发现这一点的原因、因为大多数程序员可能不关心复位问题、或者正在使用开发板、而这些开发板无意中"解决"了这一问题。 但是、对于定制硬件、这是不同的。  

但是、为了纠正行为并从公式中删除测试引脚8以返回到"预期"设置、需要理解的是：

该重叠信号会导致不复位的行为(需要)

非重叠信号会导致复位行为(不需要)

代码中的什么首先导致了测试？

如上所述、第二个复位问题是为什么内部(由 VCC_TOOL 供电)模式中的 MSP-FET 2.0+会在读取前暂时切断？

可以从此处获取两条路径之一：

1.我们放弃了以正确的方式解决问题，只是更新了用户指南，这样，我后面的下一个可怜的灵魂就不必经历这场噩梦了。

2.我们找出导致行为的原因以及我的"变通办法"的工作原理、并在代码级别实际修复此问题。

您好 Stefan、

您在这里似乎做了很多研究。

现在、主要问题是、不清楚为什么 MSP-FET 2.0在读取前具有下电上电周期。 我将尝试在我的一侧重现问题、然后 尝试诊断根本原因。

谢谢！

此致

Johnson

感谢您在这一问题上的帮助。

至于在无循环通电的情况下读取的另一个复位、我认为与 JTAG 初始化序列相关、在没有 TEST/VPP 信号的情况下使用示波器似乎是正确的。

将 TEST/VPP 信号连接到 TCK 后、会以某种方式导致 JTAG 初始化问题、但我不理解 JTAG 数据表中的内容、即这是如何导致器件无法复位的、或者器件如何在中断该信号的情况下正确选择 SBW？

我在初始化期间看到 JTAG 状态机的复位、但我怀疑这与实际器件的复位有任何关系、除非通过某种方式复位状态机也会导致 MSP 上的状态机复位？ 无论采用哪种方式、我认为该初始化信号都是问题的原因。 我只是对低级 JTAG 接口的编码了解不够清楚、无法弄清任何内容。

但大家都认为、最令人担忧的是 MSP-FET 2.0为何在内部电源模式下进行功率循环。 期待看到您的成果。

随附了一 个修改后的 MSP430Flasher.exe 以及基于 v1.3.2的修改后的源代码、其中添加了一个新选项：

 -m JTAG |                   Configure interface protocol used.
    SPYBIWIRE |              JTAG: : The normal standard 4-wire JTAG
    SPYBIWIREJTAG |                  communication.
    AUTOMATIC                SPYBIWIRE : Spy-bi-Wire (2-wire) JTAG protocol
                             SPYBIWIREJTAG: Standard 4-wire JTAG communication
                                            for MSP430 devices which also
                                            support Spy-bi-Wire (a special
                                            entry sequence is needed to switch
                                            these MSP430 derivatives into
                                            4-wire mode which cannot be applied
                                            to any MSP430 devices)
                             AUTOMATIC: JTAG communication protocol is selected
                                        automatically by the  MSPDdebugStack

如果使用-m SPYBIWIRE 、则会很有意思。

e2e.ti.com/.../MSP430Flasher.zip

e2e.ti.com/.../Source.zip

切斯特。 感谢你的帮助。 可能需要一两天时间才能尝试、但只要我能够、我就会报告结果。

出于好奇、请注意、Uniflash 是否使用 MSP430Flasher 作为基础？ 从 uniflash 导出.zip 文件时、我注意到这些文件在某些文件夹中浮动。 或者、这只是手册中引用的旧支持命令吗？

我认为 Uniflash 不应基于 MSP430Flasher。  

您是否尝试使用 Chester 提供的文件？ 还有其他问题吗？

谢谢！

所以。 我修改了测试代码、以便在每次设备启动时递增并存储在 fram 中、以便更好地确定问题的特征。

我发现在没有连接 TEST/VPP 的情况下、在原始 MSPFlasher 上、它以某种方式复位两次。 选择了-m SPYBIWIRE 的新 MSPFlasher 后、它仅复位一次、连接了 TEST/VPP 的旧 MSPFlasher 后、我不会复位。

我认为这支持我的理论、这是基于初始化序列进行某种程度的重置、我只是对低级代码不了解、无法理解发生这种情况的原因。

您好 Stefan、

我同意您的观点、但我不是最正确的人、我试图理解此问题并学习低级代码、但没有任何进展。

我可以向其他团队反馈、并尝试查看是否有进展。

谢谢！

此致

Johnson

Johnson、

感谢你的帮助。 我完全理解。 我将继续亲自尝试、看看我能得到什么。 请随时向我发布。 再次感谢。

明白了、谢谢！ 如果我从其他团队获得任何更新、我会告诉您。