This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] MSP430F5529:BSL:&quot 的原因;内存验证错误"??

Guru**** 2591830 points
Other Parts Discussed in Thread: MSP430F5529

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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/623152/msp430f5529-bsl-cause-of-memory-verification-error

器件型号:MSP430F5529

您好!

我们使用 MSP430F5529 + BSL 作为汇编语言编程和现场更新的方法。

在每8次编程尝试中、大约有1次、我们会从 BSL 工具中获得"存储器验证错误"。

输出如下:

已
成功发送启动密码
发送 RAM BSL v00.07.08.38
DONE RAM BSL v00.07.08.38
正在擦除内存段
发送 Firmware.txt
固件已发送
验证内存
验证错误 

有人能告诉我们造成这种情况的原因是什么、为什么会发生这种情况? 以及为什么这会使我们的器件处于一种欺骗状态。

谢谢。

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

    MSP430F5529上的默认 BSL 通过 USB 进行通信、并驻留在引导加载程序存储器(闪存0x1000至0x17FF)和 RAM (0x2400至0x33FF)中、这两个存储器区域必须使用 JTAG 通信编程为相同的版本才能正常工作。 上面的命令似乎是对 RAM BSL 部分进行编程、而不是对闪存 BSL 进行编程。 为什么您在没有最新版本(从修订版 K 到更高版本的版本00.08.88.39)的情况下重新对 USB BSL 进行编程?

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

    因此、可能会对 BSL 应用程序的操作有一些误解。 我们只需打开应用程序、提供我们的固件.txt 文件并让它执行它的操作。 我不确定 BSL 版本号。 我们只需购买 MSP430器件、焊接、连接 USB、对我们的应用进行编程、然后进行测试。

    这不是正确的程序吗? 我们是否应该以某种方式首先使用 JTAG 重新刷写 BSL 8.88.39?

    此致
    太棒了!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    仅供跟进。

    我已使用8.08.39 BSL_RAM 文件更新了 BSL 工具中的 firmware.resx、并调整了 BSL 工具中固件版本很重要的其他位置。

    BSL 过程现在运行得更好、实际上我没有看到任何存储器验证问题。

    但是、新问题:

    BSL 过程不再重置目标器件。 7.08x 和8.08x 之间是否有其他特殊的变化、这需要一些不同的设置来强制在 BSL 过程之后进行复位。 我之所以提出这一点、是因为在我的客户应用中、在升级后、电动自行车不是一件容易的事情。

    谢谢
    太棒了!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Stomp、

    我注意到的问题是、您发送的 RAM BSL v00.07.08.38是可以单独使用 BSL 的、我不确定原因。 您只需使用密码解锁 BSL、然后发送固件即可。 您使用什么软件和 FET 工具与 BSL 进行交互? 您可以切换 RST 行以强制进行复位、BSL 脚本编写器(SLAU655)还具有一个指向复位矢量位置的 SET_PC 命令、用于重新启动应用程序。 但是、由于 BSL 程序已经改变了需要重新配置的 CPU 频率设置、所以应该小心。

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

    您好、Ryan、

    我没有找到一些好的版本号、但我使用的是基于源代码构建的 BSL_USB_GUI。  

    显然、版本是:

    1.3.1 04/07/14 A. Bhat 将 RAM_BSL 更新为 v00.07.08.38 

    该工具工作正常、如前所述、随机未通过内存检查。

    我已经获取了这个版本并将00.08.08.39 RAM_BSL 版本应用于 Firmware.resx 文件、并在 downloadview.cpp 中更改了一些器件以适应新版本。 经过此修改后、BSL 工作良好、但重置目标硬件除外。

    Firmware.resx 中仍有一些问题涉及"forced_BOR.text"和"forced_PUC.text"值及其关联地址。  我假设这些需要随8.08.39 RAM BSL 而变化、但我不知道在哪里找到它们。

    您对 BOR 或 PUC 值的位置有什么想法吗?

    谢谢

    太棒了!

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

    您好、Stomp、

    无论使用的 BSL 版本如何、强制 BOR 或 PUC 的地址和值都不应更改。 对源代码的一些其他更改可能会阻止主机应用程序在固件更新后发出 BOR 命令。 PMMSWBOR 所需的一切就是将0xA504 (PMM 密码加上软件欠压复位)写入 PMMCTL0 @0x120。  https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/395535/ 

    此致、
    Ryan

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

    感谢 Ryan、

    我在 MSP430 BSL 工具中发现了一些时序问题。

    我修改了 DownloadView.cpp (文件中的第386行)以包括一些额外的时间延迟。 添加延迟后、器件会正确复位。

    下面是调制代码。

    Worker->ReportProgress (90、"总编程时间为"+ totalProgramTime +"s \r\n");
    
    Sleep (1000);
    Worker->ReportProgress (91、"");
    Sleep (1000);
    Worker->ReportProgress (92,"");
    Sleep (1000);
    
    //强制执行 BOR
    触发器 ForcedBOR(cwork,e);
    
    Worker->ReportProgress (100,"Done");
    e->Result = true; 

    谢谢

    太棒了!

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

    我发言太早了。

    通过在 BSL 发出延迟、重置工作正常、但我们仍然随机地(在我们的办公室和客户站点)从 BSL 工具获取存储器验证错误。

    您能否帮助解决导致验证错误的原因? 我们如何进行调试?

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

    您是否能够使用 JTAG 连接读取故障器件的已编程存储器、并将其与成功运行或预期的存储器内容进行比较? 我假设可以恢复这些器件、然后进行正确编程? 您是否考虑使用 BSL 脚本编写工具、因为其固件的更新比参考的应用手册资源更频繁?

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

    我可以连接到编程失败的器件、我可以下载和比较器件存储器、并且在各个地址之间存在显著差异、尤其是在器件末尾。

    如果有任何帮助、我还单步执行了 BSL 工具的 Check_CRC 函数(存储器验证)、我发现当从地址0x17532开始、长度为0x1198的地址请求 CRC 时、存储器验证失败。 我的应用程序的代码范围为0x4400到0x186C8。

    0x186C8的函数仅为2个字节、0x17532 + 0x1198 = 0x186C8 + 2、因此我对长度感到满意、只是对 CRC 失败感到不满意。

    同样、这个问题在本质上是随机的、目前大约30%的故障率、但这30%会导致电路板变砖。

    我将查看脚本编写工具、但我认为 BSL 是一个经过良好测试且稳定的系统吗?

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

    BSL 外设是一个经良好测试且稳定的系统、但是所涉及的软件编程器可能会遇到大内存地址(>0xFFFF)问题。 似乎器件存储器末尾的差异涉及时序问题、因此我想知道如果改用脚本工具会发生什么情况。

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

    我知道这条线程稍微有点旧、但我将结束我们的调查结果。

    我们最后在.NET 中重新编写了 MSP430 BSL Windows 工具、发现了一些值得注意的事情:

    1、每次 HID 报告都将失败并出现超时。 我想 BSL 工具无法确定是否发生了此故障、尤其是在快速写入模式下。

    2.我们继续遇到内存错误,但仅当程序大小增加时。 我们认为我们在0x18000以上看到错误的原因是内存的部分没有被正确擦除、因此未能通过 CRC 校验。 擦除闪存扇区后、我们在 BSL 工具中添加了一些额外的代码、以擦除最后一个存储器地址之后的另一个512字节。 这似乎完全消除了问题、我猜擦除时页面大小有一些限制? (即、我们的程序大小大于存储器擦除大小)。

    此外、我们还在最后一次闪存擦除之后、编程开始之前增加了一个小延迟、不确定这是否已经进行了任何改进。

    我们没有尝试使用 BSL 脚本编写工具、因为我们认为它太难适应我们的工作流程。

    谢谢。