[参考译文] MSP430F5310：自定义 BSL

还有一点：

6.我能够下载 BSL 项目、通过配置调试/闪存设置、我能够将 BSL 下载到闪存。 我可以通过在 PC 值达到 main ()时改变 PC 值来完成我添加的 CRC 函数。 不过、当我尝试通过任何 BSL 访问相关线路进行单步执行时、例如

BIS #SYSBSLPE+SYSBSLSIZE0+SYSBSLSIZE1 ,&SYSBSLC ;保护 BSL

这导致调试接口再次锁定、并且丢失了一个部件。

问题在于 JTAG 熔丝值被存储在最后一个 BSL 闪存段内、地址为0x17FC 至0x17FF。 默认出厂(JTAG 未锁定)值为0xFFFFFFFF。 JTAG 也将通过保险丝值0x00000000解锁。 无论使用任何其他熔丝值(可能被定制版本的尺寸增加覆盖、检查生成的二进制中的0x17FC 值)、JTAG 将被锁定、同时使用不稳定的 BSL、器件将会变砖。 如果您可以在 JTAG 锁定器件上使用 BSL 在0x17FC 写入四个零字节(无需擦除任何内容、只需写入)、它们应该会被解锁。

在处理 BSL 时、我仅使用了主闪存。 上电/复位器件时、开始像任何其他程序一样从主闪存执行 BSL 代码。 BSL 已复制到 RAM 并在其中执行、主闪存已被擦除、并为更新做好准备。 开发结束时、当我100%确定一切都运行正常时、我将 BSL 从主闪存移到了 BSL 闪存区域。 零砖型设备完成项目。 BSL 仍被复制到 RAM 端并在此处执行。

如果我没记错、BSL 是某种特殊的闪存区域、在该区域中不支持断点调试(与 BSL 保护位无关)。

您好！

感谢您的回复！
我已经检查了位置0x17FC - 0x17FF、它们很好、内存没有溢出到这些区域中、并且它们至少在二进制 TXT 文件中仍然是0xFFFF。

您提到了使用我自己的 BSL 将四个零字节写入0x17FC、但由于 JTAG 已锁定、我无法将新的 BSL 刷写到器件中。 您能解释一下如何操作吗？ 我能否使用工作中的 BSL 来刷写新的 BSL 或修改这些闪存位置？

许多年前、您发布了一些用于解锁的脚本、请您在此处发布它们吗？ 那个老帖子有死链接,我无法获得脚本。 我指的是您发布的这个位置： http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programr/?p=44019

谢谢。

阿伦

您好！

我在一群砖砌的 IC 上试过这个、所有这些 IC 的 BSL 代码实际上都做得很好、所以我知道 BSL 是有效的。 我还通过其他方式进行了测试、表明 BSL 在所有这些中都能正常工作。

但是、这并没有导致 JTAG 解锁。 我有一半的预期、因为我的代码从未写入闪存、存储器也没有超过、因此0x17FC - 0x17FF 存储器已从所有 FFs 中更改。 我的链接器控制文件也会报告此问题。

非常感谢您的帮助。

但我现在归结到我的最后一部分,仍然不知道如何发生的诱惑。 我已经在应用程序空间项目上测试了 CRC 代码、运行正常。 因此、我怀疑其他问题是问题的根源。 即使我订购了更多的部件、我也不知道如何避免所有部件的磨损。

例如、可以在 BSL_PROTECT 函数中使用/更改其他寄存器 R13、R14、R15吗？

BSL_PROTECT 功能是否可以使用栈？

谢谢。

阿伦

如果我记忆右解锁 BSL (闪存段)、读取将返回零。 因此、如果您的 BSL 工作正常并且闪存段被解锁、那么首次读取0x17FC 时应该返回0xFF 值。 用零重新写入后、读取0x17FC 应返回0x00。

有时、JTAG 主器件可以报告熔断的 JTAG 保险丝、即使保险丝值未更改(出厂默认值)。 我在刷写器件固件不稳定的情况下发现了这种情况。 通过 BSL 批量擦除或使器件"冷却"几个小时来清除此状态。

R12在 BSL PROTECT 功能中用作返回值。

您好！

我现在已经锁定了我的最后一个部分,我仍然不知道原因是什么。 我已经消除了其他一些疑问、例如、我不再使用堆栈、并且我将 CRC 调用为函数、而是汇编。

BSL 仍然可以工作、因为我可以将新的应用程序加载到器件中、不会有任何问题。

我现在很确定所有这些器件都已锁定、因为我违反了适用于 BSL_PROTECT 函数的某些规则。 例如、我将 R13、R14、R15用作暂存寄存器、并正如您所提到的、我将在 R12中返回值。

以下各项是否有某种限制：

BSL_PROTECT 有多大? 我通过链接器文件确保整个 BSL 大小符合所需的2KB 大小、并且0x17F0-0x17FF 中的值是正确的。

- BSL_PROTECT 是否可以使用 R13/R14/R15？

现已达到紧急级别、希望 TI 的相关人员能为您提供帮助！

谢谢。

阿伦

您好！

我在 SLAA450G 中找到了一个有趣的段落：

调用 BSL 保护功能时、将堆栈指针设置为一个默认位置、该默认位置取决于器件。 更改堆栈指针或操作堆栈指针数据值很可能会导致器件无响应。 在这种情况下、不可能执行任何操作、甚至无法重新编程。 在某些器件上、栈指针空间非常有限、并且在 BSL 保护函数中广泛使用栈指针可能会导致内存溢出。 为了确保行为正确、应限制堆栈访问或将堆栈指针移至另一个位置。 为确保器件正确地从 BSL PROTECT 功能返回、必须在返回之前恢复栈指针。

因此这证明使用 SP 不是一个好主意。 我已经通过试错学习了这一点,不再使用它了。

但它并未提及 R13/R14/R15的使用情况。

另一个有趣的段落是：

返回函数中过长的延迟可能会导致调试期间出现问题。 在最基本的情况下、BSL 保护功能应该执行两个基本操作：保护 BSL 存储器以及在退出 BSL 保护功能后确定应该执行 BSL 还是用户代码

但并不是很具体。 例如、是否认为 CRC 循环延迟过大？

谢谢。

阿伦

我只需检查具有 USB 硬件模块的 MSP430器件的 CDC BSL。 PROTECT 功能总共有10条汇编器指令、用于保护 BSL 并检查 PUR。 除了 R12、我没有使用任何其他寄存器。

如果 BSL 在带块的器件上工作正常、您可以更新 MAIN 闪存、您可以为 MAIN 闪存编写简单的程序、该程序将解锁并擦除所有 BSL 段、还可以整体擦除 MAIN 闪存。 完全擦除的器件(BSL 和 MAIN)应该能够与 JTAG 正常配合使用。 那么您可以重新写回到原始出厂 BSL、然后重新启动。

您好！

谢谢您的建议、我将尝试一下。

但 JTAG 锁定原因的问题仍然没有解决。 除非我弄清楚、否则我肯定能让更多器件实现砖型化。

我能想到的唯一一件事是、我不应该使用 R13/R14/R15、或者应该使用并恢复它们。 我将尝试在收到可用的新器件时进行更新、我已经订购了这些器件。

谢谢。

阿伦

尊敬的 Arun：

您是否需要针对此问题的其他支持？

谢谢！

此致

约翰逊

您好、Johnson：

是的、我想帮大家弄清楚为什么我犯了这么多芯片 JTAG 设计错误。

我明天会得到一批新的6个 MSP430F5310、我将尝试一些想法、但实际上我主要是两个想法：

-保存/恢复在我的 CRC 循环中使用的 R13/R14/R15、以便它们保存在 BSL_PROTECT 中

- CRC 循环所花费的额外时间是否会导致一个问题,例如看门狗或其他问题?

欢迎就这一问题提出具体建议！

谢谢。

阿伦

更新：

我收到了新的 IC、并一次性尝试了上述两个想法、现在芯起问题已经解决了！
上述的一种或两种猜测是正确的。
最好从 TI 获得必需的确认、这样我就不会再砖墙以试图隔离问题。

谢谢。

阿伦

尊敬的 Arun：

请允许我咨询 BSL 专家、然后向您反馈这一根本原因。

谢谢！

此致

约翰逊