[参考译文] MSP430G2553：BSL同步失败

目前，我只能使用一个工作信道，但我会看看我是否可以钻一些东西来显示这两个信号。

但我想暂时把触发问题搁置一边，并解决一个更基本的问题。  我在G2553中设置了代码，这样在启动时它会跳转到冷启动BSL矢量，所以不需要触发/RST和测试。  然后我尝试使用bsldemo2读取内存的一部分。  结果如下：

C：\ti>bsldemo2.exe -cCOM4 -pPW1.txt -r0xD000 0x0100 read.txt +u
MSP430引导加载器通信程序(版本2.01)
将内存读取为文件：read.txt开始：0xD000长度0x100
 读取内存开始：0xD000长度240
错误：通信错误！

PC在 35毫秒的时间内传输一系列字节，以0x80开头。  在此期间，2553的响应 间隔相当均匀，为4个字节。 第一个看起来很像8/E/1中的0x90，我想其他三个也是。

密码文件如下所示：

@FFE0
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF C0 10.
问

我的适配器的驱动程序设置为9600波特，8/E/1，这就是slau319所说的。

所以实际上，一切似乎都是有效的。  但显然有些错误。  毫无疑问，我的PIN正确，端口设置也正确。  但bsldemo2认为某事是错误的。

我应该说，我使用了此适配器，使用TI提供的非常简单的自定义协议将软件刷新到G2231，并且所有这些都工作正常。

所以我很困惑为什么它不起作用。  我也很好奇“长度240”的来源，除非这是两个数据包中的第一个。  2553不会开始发送读取数据，因此它似乎是波特率不匹配或类似情况。

我希望你能明白我做错了什么。  我假设bsldemo2在过去的某个时候确实与G2553合作过。

您好，George，

您是否检查了您最初编程的代码是否未按照slau319中所述禁用BSL

此致，
Dietmar

好的，我已经弄清楚了/Reset Test BSL启动序列的问题。  DTR和RTS都完全按照预期执行(根据slau319)，但DTR是反转的。  因此，它与所需的模式相反，并在结束时返回复位 。因此难怪它不起作用。  不过RTS正常。  我不知道为什么只有一个是反向的，但我想所有这一切都源于计算机有真正的串行端口时，所以谁知道极性的假设。  但您知道，我们已经拥有这些USB到串行适配器一段时间了，我希望TI能够制造出一个可以直接使用它们的BSLDEMO版本，而不需要反相器。  如果有这样的版本，请有人给我一个链接。

但更令人担忧的是，当我绕过特殊的启动顺序并直接跳到BSL冷启动时，我会遇到通信错误。  字节是双向传输的，因此除非我给出了非法指令，否则它几乎必须是波特率不匹配或奇偶校验不匹配。  我可以在8/E/1看到BSL发送，因为我可以在传输0x90时看到零奇偶校验位。  但是我不能确定BSLDEMO2，因为0x80有一个部分位，它与停止位相同。  它是否也使用偶校验？

我知道这是在弃用 的文件夹中，但芯片仍在出售，它在ROM中仍然有BSL，所以应该有软件可以工作。

下面是三个额外的照射行程。  第一个问题很重要，因为它似乎已经完成，它说它正在发送密码，而最后两个问题没有提到这一点。  如果未发送密码，这可能说明出现故障的原因。  事实上，如果我根本不包含密码文件，则错误是相同的。  是的，我肯定密码正确。

C:\TI>BSLDEMO2.EXE -cCOM4 -PPW.TXT -m2 +u
MSP430引导加载器通信程序(版本2.01)
将质量擦除周期数设置为2。
无设备重置-从用户程序调用BSL ---------------------------
传输PSW文件"PW.TXT"。
BSL版本：2.03 -家庭成员：2553 -流程：0060
程序/验证：0.0 sec -整体：5.0457万.4 sec

C:\TI>BSLDEMO2.EXE -cCOM4 -PPW.TXT -m2 -rD000 40 saveit.txt +u
MSP430引导加载器通信程序(版本2.01)
将质量擦除周期数设置为2。
将内存读取为文件：saveit.txt开始：0xD000长度0x40
 读取内存开始：0xD000长度64
错误：通信错误！

C:\TI>BSLDEMO2.EXE -cCOM4 -PPW.TXT -m2 +UV PW.TXT
MSP430引导加载器通信程序(版本2.01)
将质量擦除周期数设置为2。
验证"PW.TXT"。
检查从ffe0开始，32字节... 错误：7
错误：通信错误！

我不明白发生了什么。  有人能告诉我我我做错了什么吗？

编辑：

这是另一个成功的运行，这次涉及句段擦除，再次明确声明它发送了密码。  很显然，它不会为所有受密码保护的命令发送密码。  为什么会这样？  我如何做到这一点？

C:\TI>BSLDEMO2.EXE -cCOM4 -PPW.TXT -eE000 +u
MSP430引导加载器通信程序(版本2.01)
传输PSW文件"PW.TXT"。
BSL版本：2.03 -家庭成员：2553 -流程：0060
Erase segment (擦除段)：0xE000
程序/验证：0.0 sec -整体：0.1 sec

此操作也已完成，但即使发送了密码，也完全忽略了Read命令。

C:\TI>BSLDEMO2.EXE -cCOM4 -rD000 40 saveit.txt -1 -PPW.TXT -eE000 +u
MSP430引导加载器通信程序(版本2.01)
传输PSW文件"PW.TXT"。
BSL版本：2.03 -家庭成员：2553 -流程：0060
Erase segment (擦除段)：0xE000
程序/验证：0.0 sec -整体：0.1 sec

我仍然不知道发生了什么。  但至少我认为"通信错误"并不是这样。

我想我终于明白了。  由于我没有使用DTR和RTS信令模式，所以我在BSLDEMO2命令行中使用了+u参数，该参数表示跳过发送该模式。  但是查看程序的源代码时，由于某种原因，如果 使用+u，它会跳过发送多个命令的密码。  这意味着这些命令将在G2553上失败，因为它需要密码。

所以我回去，在没有+u的情况下再次尝试，只是让它执行DTR/RTS信号，即使这些线路上没有任何连接，并且读取和验证命令都正常工作。  所以我认为这就是答案。

这就没有了反转DTR线的问题。  在软件中是否可以对此采取任何措施？  如果可以在软件中修复逆变器，则为其添加部件似乎是一种耻辱。  TI是否提供了没有该反转的版本？

您好，Geroge：

很好地听到您的解决方案，但我对具有反向数据传输线的项目不太清楚。 通常，如果您使用BSL Rocket接口，则工作正常。

那么，您使用哪种硬件作为PC串行端口和目标设备之间的接口。 也许您可以发布图片以获得更好的理解。 另外，如果能对信号进行范围拍摄，我可以与我们团队中的BSL利益相关者讨论这一问题。

谢谢！
Dietmar

第一张图片显示了初始序列中的RTS-测试行。  如您所见，它与slau319中的工程图相同，适用于具有共享JTAG引脚的G2553等部件。  第二张图片是DTR-重置行，如您所见，它与所需的模式反转。  它应该是常高的，然后走低的路开始模式，然后在正确的时间回到高的位置，留在那里。  我很抱歉没有工作的双通道范围，但我认为这些图片显示了每条线路上发生的情况，尽管不是两条线路之间的相对时间。  但是很明显，DTR-Reset是反转的，因为它在序列之后保持低电平，这将使芯片保持永久复位。  当然，它应该保持较高的水平。

我不想使用像Rocket这样的外部设备，而是想在项目设计中嵌入一个USB到串行芯片，以便只需一根USB电缆即可完成闪存。  为此，我将使用CP2102。  出于试验目的，我使用的模块包含CP2102，其电容器， USB连接器和一些指示灯，但在功能上它只是CP2102。  此部件与其他类似的USB桥接芯片(如FT232和CH340)类似，我相信TI也有一个用于Launchpad-G2的芯片。  这些芯片在与BSLDEMO编写环境不同的环境中运行，在该环境中，计算机实际上具有串行端口。   不存在slau319的硬件部分所述的版本或双版本，也不需要DTR和RTS提供电源。   如果BSLDEMO直接与USB桥接芯片配合使用 ，而无需使用额外部件将DTR反转至正确的极性，这将是很好的。

我知道这都是弃用的东西，但是BSLDEMO2仍然是唯一允许1xx，2xx和4xx部件的BSL闪存的软件，并且应该有一个与这些USB适配器兼容的版本。  我认为对版本2.01 的源代码所需的唯一修改 是更改bslcomm.c的第72行：

发自：

 comDCB.fDtrControl =级别？ DTR_CONTINT_ENABLE : DTR_CONTINT_DISABLE；

至：

  comDCB.fDtrControl =级别？ DTR_CONTINT_DISABLE：DTR_CONTINT_ENABLE；

或者，也可以使用命令行选项来反转DTR极性。

我可以进行更改并重新编译，但对于有相同需求的其他人，我认为他们从TI而不是从我那里下载新的可执行文件会更安全。  因此，我希望TI将提供一个新版本来解决此问题。  很多人都喜欢G2553，但没有人再使用串行端口，因此我们需要该软件来与每个人都使用的USB适配器配合使用。

我能够使用LCC编译器编译源代码，在进行了上一篇文章中描述的单行更改后，触发模式现在可以与分别直接连接到 G2553上的/重置和测试的CP2102的DTR和RTS输出一起使用。  所以DTR的极性无疑是问题所在，修复工作很有效。  我相信 其他 广泛使用的USB到串行适配器- FT232RL和CH340g也是如此。

反思一下，我认为如果TI有兴趣提供2.02 版本的BSLDEMO，最好的方法是提供一个新的“+”计划流说明符选项， 可能"i"或"d"表示"反转DTR线"，默认+选项中不会包含该线。  然后， 现在与v．2.01 一起使用的所有硬件将继续与v．2.02 一起使用同一命令行。  但是需要反转的新硬件可以使用2.02 v和指定的新选项。

我希望有办法做到这一点。

感谢Dietmar，但我认为我们都知道，如果没有目标完成日期，下一版本的已过时程序可能永远不会出现 ，但我非常感谢您努力将我的顾虑告知TI的相关人员。

如果没有人反对，我可能会编译我自己的BSLDEMO版本，并提供反转DTR的选项，然后将其发布到Github或一些类似的托管站点，并附带TI版权声明。  出于安全原因，我知道大多数人更喜欢从TI下载可执行文件，但我也会为那些喜欢自己编译的人发布修订后的源代码。  我认为TI对此没有任何反对。  FlyingCampDesign已经做了非常相似的事情，显然是在TI的支持下。

Georg，

对于您要对自己的BSLDEMO所做的更改，没有任何异议，请将其发布在GitHub上。 我仍然没有应发布BSLDEMO 2.02 的日期。

此致，
Dietmar