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.

[参考译文] CC430F5133:MSP430_Secure ()在清除 JTAG 签名后失败

Guru**** 657500 points
Other Parts Discussed in Thread: UNIFLASH, MSP-FET, MSPBSL
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/847238/cc430f5133-msp430_secure-fails-after-clearing-jtag-signature

器件型号:CC430F5133
主题中讨论的其他器件:UNIFLASHMSP-FETMSPBSL

我正在使用一个编程工具、该工具执行的序列与此处所示的序列非常相似:

成功编程 CPU 后,我的工具名为 MSP430_Secure(),一切都成功了。  我验证了 CCS 中和使用 UniFlash 工具禁用 JTAG 接口的情况。

接下来、我编写了一些代码、使用 BSL 接口通过复位/测试/ TX/RX 线将 JTAG 接口重新启用到 CPU。  我使用的序列是:

1) 1)发送"Rx 密码" BSL 命令、其中包含密码的所有0xFF。 这会导致器件批量擦除。 我已验证之后是否收到成功确认消息。

2) 2)我想查看0x17FC-0x17FF 中的 JTAG 签名字节当前设置为什么、因此我发送了"Tx 数据块" BSL 命令并验证返回的值既不是0x00000000、也不是0xFFFFFFFF。  我不记得返回的实际值是什么--它是0x555555或0xC5C5C5C5。

3) 3)我发送了"Rx 数据块"命令、将0x00000000写入地址 0x17FC-0x17FF。  这也返回了成功的 Ack。

完成这些步骤后、JTAG 接口再次工作。  我可以使用 UniFlash 读取器件、也可以通过 CCS 下载和调试代码。

这是个问题...

我再次尝试使用我的自定义工具重新编程 CPU、该工具在末尾调用 MSP430_Secure ()、但现在 MSP430_Secure ()调用失败、出现错误"Could not secure the device (无法保护器件)"。

如果我再次尝试使用 UniFlash 保护 CPU、我会得到相同的错误。

我在这里看到了一个讨论(http://microcontrollers108.rssing.com/chan-64320859/all_p1249.html),有人提到可能需要使用第一个参数设置为 CONFIG_JTAG_LOCK_5XX 来调用 MSP430_Configure(),但所有尝试都失败了,没有任何文档可以帮助解释这一点。

我缺少什么? 我需要通过 BSL 命令写入什么才能使 CPU 恢复到可以通过 MSP430_Secure()再次对 CPU 进行编程和禁用 JTAG 的状态?

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

    你(们)好 Bob

    您使用什么主机与 BSL 进行通信? 如果是 PC、我建议您使用 BSL 脚本编写器、我们为 JTAG 锁定和解锁演示提供了演示代码。 有关更多详细信息、请参阅用户指南第41页  

    此致

    Gary

    MSP430_Secure

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

    我使用 PC、但我使用的是自定义硬件、因此无法运行 BSL 脚本。

    我从脚本中看到我需要运行这些 BSL 命令:

    批量擦除
    RX_PASSWORD
    RX_DATA_BLOCK JTAG_UNLOCK.txt

    其中 JTAG_UNLOCK.txt 是向地址0x17FC 写入0x00的4字节数据。

    我有一个示波器连接到 Tx/Rx UART 线路、这正是我实现的序列、对于每条命令、BSL 都会返回一个成功的 Ack。

    之后、当我将我的 MSP-FET 编程器连接到我们的编程夹具上的 JTAG 连接器时、我可以从 CCS 调试器下载并运行代码、但是如果我尝试运行我的编程实用程序并调用 MSP430_Secure () API、我仍然会得到"无法保护器件"错误。

    您能否查看 MSP430_Secure()源代码并告诉我它为什么会因该错误代码而失败?  正如我之前所说的、即使是 UniFlash 也无法保护 CPU 的安全。  它还会显示相同的错误消息。

    我正在使用的 MSP430.DLL 版本是 3.13.0.1

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

    你(们)好 Bob

    您是否尝试 过 Flash_LockJtag 演示?

    您 的定制硬件的功能是什么? 您有它的原理图吗?

    您有 MSP-FET 吗?

    此致

    Gary

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

    是的、我有一个 MSP-FET。  这是我一直与 UniFlash 一起使用的 JTAG 接口,通过 MSP430_Secure()测试 CPU 锁定情况。

    您能否在 msp430.DLL 中与我共享 MSP430_Secure()的源代码?  我想了解该函数如何失败。

    Flash_LockJtag 演示执行以下操作:

    批量擦除
    RX_PASSWORD
    RX_DATA_BLOCK JTAG_LOCK.txt

    其中 JTAG_LOCK.txt 是对地址0x17FC 执行4字节写入0xAA。

    我修改了工具以执行此序列、我在 RX_DATA_BLOCK 命令的作用域中得到的结果为:

    发送到 BSL: 0x80 08 00 10 FC 17 00 AA AA AA AA AA 29 BD

    从 BSL 接收: 0x00 80 02 00 3B 01 41 D4

    BSL 手册显示错误0x01为"存储器(例如、闪存或 FRAM)写入检查失败。 编程后、对编程的数据运行 CRC。 如果 CRC 与预期结果不匹配、则返回此错误。"

    如果我读取0x17FC 处的字节、它们都是零。  我假设必须缺少一些操作来"擦除"这些字节、以使它们返回0xFFFF、然后才能再次写入0xAAAAAAAA。  也许这就是 MSP430_Secure()也失败的原因(即使它使用 MSP-FET JTAG 接口而不是通过 UART 使用 BSL 命令)。

    我还尝试使用此序列将 FF 写入0x17FC、但当然也失败了:

    发送到 BSL: 0x80 08 00 10 FC 17 00 FF FF FF FF FF 73 3A

    从 BSL 接收: 0x00 80 02 00 3B 01 41 D4

    我可以发送哪些 BSL 命令来将0x17FC 处的 JTAG 签名恢复到0xFFFFFFFF?

    我正在使用的定制板是一个密钥卡、我们的编程夹具通过一组钉床引脚与其连接、使我们能够访问 BSL 通信所需的复位、测试、RX 和 TX 线路。

    我没有权限在公共论坛上分享这些原理图。

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

    [引用 user="Bob Lawson">您能否在 msp430.DLL 中与我共享 MSP430_Secure()的源代码?  我想了解该函数如何失败。源代码可在  http://www.ti.com/tool/MSPDS 上的 MSPDS-OPEN-SOURCE 链接中找到

    请注意、可用的最新源代码是 slac460y、其中包含版本3.13.0.001、而在 CCS 9.2中、使用版本3.14.0.000。

    对于 MSP430_Secure(),我认为调用树是:

     DLL430_v3\src\DLL430_capi.cpp 中的 MSP430_Secure ()-> DLL430_OldAppiV3::::Secure () in DLL430_v3\src\DLL430_OldApiV3.cpp -> DeviceHandleMSP430::::secure () in DLL430_v3\src\TI\DLL430\DeviceHandleMSP430.cpp

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

    我仍在努力安装和构建所有组件、以便能够尝试对此进行调试。  我不确定是否能够成功构建它。

    您能回答之前的观察结果吗?

    "如果我读取0x17FC 处的字节、它们都是零。  我假设必须缺少一些操作来"擦除"这些字节、以使它们返回0xFFFF、然后才能再次写入0xAAAAAAAA。  也许这就是为什么 MSP430_Secure()也失败的原因(即使它使用 MSP-FET JTAG 接口而不是通过 UART 使用 BSL 命令)。"

    为什么不向引导加载程序发出批量擦除命令会导致0x17FC 处的字节擦除回到0xFFFF 状态?  我需要向引导加载程序发送什么来擦除它们?

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

    [引用用户="Bob Lawson">为什么不向引导加载程序发出批量擦除命令会导致0x17FC 处的字节擦除回到0xFFFF 状态?    0x17FC 处的 JTAGLOCK_KEY 字节位于0x1600中的"BSL 3"闪存段的上部。 0x17FF。 从 BSL 闪存段运行的 BSL 不能仅擦除 JTAGLOCK_KEY 字节、也不能擦除 BSL 本身的一部分。

     MSP430BSL_1_01_00_01\ccs_BSL_Source\API\BSL430_API.c (从 MSPBSL_CustomBSL430下载)中的 BSL430_massErase ()函数设置 MERAS + ERASE 位:

    FCTL1 = FwRamKey + MERAS + ERASE; //设置批量擦除位 

    CC430系列用户指南 解释了设置 MERAS 和 ERASE 位不会擦除 BSL 段:

    [引用 user="Bob Lawson"]"如果我读取0x17FC 处的字节、它们都是零。  我假设在将这些字节再次写入0xAAAAAAAA 之前、必须缺少一些操作来"擦除"这些字节、以将其恢复到0xFFFF。查看 MSPDS-OPEN-SOURCE 代码和 MSPBSL_CustomBSL430代码、我看不到任何现有的机制只擦除  0x17FC 处的 JTAGLOCK_KEY 字节。 要擦除  JTAGLOCK_KEY 字节、您必须按照以下行执行一些操作:

    a.从 0x1600中读取 BSL 3段的现有内容。  0x17FB。

    b.擦除整个 BSL 3段。

    c.从 0x1600中重新编程 BSL 3段之前的内容。  0x17FB 已保存。

    注:

    -使用 BSL 尝试上述操作首先需要下载基于 RAM 的 BSL、因为 BSL 3段包含闪存 BSL 程序的一部分。

    -要在使用 MSP-FET JTAG 接口时擦除 BSL 3段、您可能需要使用 MSP430_Configure (UNLOCK_BSL_MODE、...) 以首先解锁 BSL 段。 我尚未测试 BSL 是否默认锁定。

    - MSPBSL_CustomBSL430附带一些预构建的 BSL 映像、这些映像采用 TI 文本格式 MSP430BSL_1_01_00_01\Released_BSL_Images\CC430_Family。  擦除所有 BSL 段、然后使用 MSP430_ProgramFile()通过 MSP-FET JTAG 接口对完整的 BSL 映像进行编程、而不是仅擦除 JTAGLOCK_KEY 字节。 这可能会更改闪存中的 BSL 版本。

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

    这似乎变得过于复杂。  我认为我需要备份并重新考虑我们正在做的事情。

    我要做的是:

    a)创建一个使用 MSP430.dll API 通过 JTAG 接口对 CPU 进行编程的编程工具。  (由于我们的编程 JIG 也有用于通过 BSL 对 CPU 进行编程的电路、我可以完全放弃 MSP430 API 并仅使用 BSL 命令、但这对我来说更有用。)

    b) CPU 编程后、JTAG 接口应锁定、以避免黑客读取代码。  如果这是使用 MSP430_Secure()等 MSP430 API 调用来完成的,或者我们编程到闪存中的代码在第一次启动时自动执行某种操作来禁用 JTAG,这对我来说无关紧要。

    c)我希望该选项能够通过 BSL 整体擦除 CPU、并在稍后我们在代码中发现错误时全面启动。

    目前、我可以执行步骤 A、B 和 C、然后使用步骤 A 重新开始、但在第二次尝试运行步骤 A 时、正如我之前所解释的那样、MSP430_Secure()调用每次都失败。

    是否有其他解决方案可以实现我要做的事情?  我是否应该避免使用 MSP430_Secure()并使用其他一些方法来禁用 JTAG?

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

    [引用用户="Bob Lawson]这似乎变得过于复杂。  我认为我需要备份并重新考虑我们正在做的事情。[/QUEST]好的、我理解您正在尝试做什么。 根据 CC430器件的公共信息、 MSP430.dll 源代码和 BSL 源代码,我试图了解导致 MSP430_Secure()失败的原因。

    至于 JTAG 保护:

    a: 地址 0x17FC.0x17FF 处的 JTAGLOCK_KEY 字节、如果具有任何其他值0x0或0xFFFFFFFF、则会锁定 JTAG 访问。

    b.当在 TI 制造期间闪存 BSL 被编程到 CC430器  件中时、JTAGLOCK_KEY 被设定为0xFFFFFFFF、即保持闪存擦除状态。

    c. 用于 CC430 的 MSP430_Secure ()的工作方式是将值编程到 JTAGLOCK_KEY 字节中以锁定 JTAG。 查看 slac460y 代码、写入 JTAGLOCK_KEY 的值具有默认值0xCACACA、这是  slac460y\BIOS\src\hal\macros\Configure.c 中 JTAGLOock5xx 变量的初始值  MSP430_Configure (CONFIG_JTAG_LOCK_5XX)可被用于改变 MSP430_Secure ()写入 JTAGLOCK_KEY 的值。

    d.在尝试对 JTAGLOCK_KEY 字节进行编程之后, MSP430_Secure ()通过确定器件是否处于 JTAG 旁路模式来检查 JTAG 是否被锁定。

    e. 由于 MSP430_Secure ()只执行闪存编程操作、它只能将位从被擦除的'1'状态更改为'0'。 根据您的步骤、在步骤 a 的第二次尝试中、JTAGLOCK_KEY 字节将为0x0、随后使用 BSL 解锁 JTAG、因此 MSP430_Secure ()将无法重新锁定 JTAG。

    [引用 user="Bob Lawson]根据我在上面的分析,我是否应该避免使用 MSP430_Secure ()并使用其他一些方法来禁用 JTAG?我认为避免使用 MSP430_Secure ()将会有所帮助; 问题是、为了允许第二次成功尝试禁用 JTAG、必须首先擦除包含 JTAGLOCK_KEY 字节的 BSL 3段。 由于 BSL 3段也包含 BSL 程序的一部分、因此在擦除 BSL 3段后、需要对 BSL 进行重新编程。

    [引用 user="Bob Lawson"](由于我们的编程夹具也具有通过 BSL 对 CPU 进行编程的电路、因此我可以完全放弃 MSP430 API 并仅使用 BSL 命令、但这对我来说更有用。)也许您的 A)可以更改为:

    1读取 JTAGLOCK_KEY 字节的内容。

    2.如果 JTAGLOCK_KEY 当前是0xFFFFFFFF 以外的值、则重新编程 TI-BSL 映像:

    -调用 MSP430_Configure (UNLOCK_BSL_MODE、ENABLE)来解锁 BSL 存储器。

    -调用 MSP430_Erase (ERASE_ALL、0、0)、这将擦除主存储器、信息存储器和 BSL 存储器。 不确定信息内存中是否有需要保留的数据。

    -调用 MSP430_ProgramFile()以对预构建的 TI-BSL 映像进行编程。

    3.继续对应用程序进行编程。

    很抱歉、上述内容有点含糊、但我不是 TI 员工、目前没有带 BSL 和 JTAG 连接的硬件来尝试上述建议的更改。

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

    非常感谢您花时间在您甚至不为 TI 工作时提供如此详细的响应。

    我认为您提出的解决方案可能适合我。  我会尝试一下并发布结果。

    Bob

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

    我验证了您的解决方案是否有效。

    再次感谢您花时间帮助我。

    Bob