主题中讨论的其他器件： UNIFLASH、 MSP-FET
工具与软件：
在 BSL (引导加载程序)模式下使用 UniFlash 对 MSP430F67791A 进行编程时、我们遇到了一些密码 CRC 验证问题。
这与以下票证非常相似：
MSP430FR2433：使用 Uniflash 通过 BSL 对存储器进行编程时出现问题
使用的工具/设备
- UniFlash 版本：8.1.1.4146和9.0.0.5086 (旧版本和最新版本也出现相同问题)
- MSP-FET 调试器/编程器
- MSP430F67791A
该设计的链接
希望以下示例突出显示了该问题：
- 使用 UniFlash 通过 JTAG 接口对器件进行编程(无需密码)。
- 程序的十六进制数据已知。
- 0xFFE0处的密码数据是已知的。
- 我们加载的软件是 V1.0
- 断开 UniFlash 和 MSP-FET 编程器并检查程序运行
- 没有问题、程序按预期运行。
- 连接 MSP-FET 编程器并使用 UniFlash 再次对器件进行编程、但这次使用 BSL (引导加载程序)模式(需要密码)。
- 程序的十六进制数据已知并且与 V1.0不同
- 0xFFE0处的密码数据是已知的、并且与 V1.0不同
- 我们加载的软件是 V1.1
- 当 BSL 检查地址0xFE00 (密码数据的位置)时、验证失败。
密码
v1.0密码数据如下：
@FFE0
E0 C0 DE C0 FF FF FF DC C2 7E C2 DC C0 B0 C1
84 C0 38 C0 FF FF 20 C2 FF FF FF FF FF 00 C0
问
v1.1密码数据如下：
@FFE0
E0 C0 DE C0 FF FF E0 C2 82 C2 DC C0 B0 C1
84 C0 38 C0 FF FF 24 C2 FF FF FF FF FF 00 C0
问
正如预期的那样、2个密码之间有些字节是不同的。
UniFlash 设置
此时已加载"TEST_V1.0.txt"、我们选择 V1.0软件的密码文件。
选择要加载到器件中的"test_v1.1.txt"、这将覆盖 V1.0软件。
我的理解是、所选密码文件必须与当前编程到器件中的密码数据相匹配-在本例中、V1.0软件的密码数据就是这样。
CRC 故障
使用 V1.1软件对器件进行编程并验证后、地址0xFFE0 (即密码地址)出现故障：
UniFlash 期望密码 CRC 为0xA366、但器件的引导加载程序将计算并返回0xFB55。
我使用 MSP430闪存器件引导加载程序(BSL) 文档对进出器件的传输进行了解码、该文档显示了如下命令和响应：
- 来自 UniFlash 的命令：[80][06][00][16][E0][FF][00][20][00][3C] EF
- 80 =接头
- 60 00 = 0x0006 (数据包中的字节)
- 16 ="CRC 检查"
- E0 FF 00 = 0x00FFE0 (地址)
- 20 00 = 0x0020 (长度、即32字节、密码长度)。
- 3C EF = 0xEF3C (数据包校验和)
- 来自 MSP430的回复：｛00｝｛80｝｛03｝｛00｝｛3A｝｛55｝｛FB｝｛C6｝｛61｝
- 00 =来自 MSP430的 ACK、指示命令数据包有效
- 80 =接头
- 03 00 = 0x0003 (数据包中的字节)
- 3A ="CRC 值"
- 55 FB = 0xFB55 (CRC 由 MSP430引导加载程序计算)
- C6 61 = 0x61C6 (数据包校验和)。
因此、UniFlash 使用"TEST_V1.0.txt"软件(当前加载到 MSP430)的密码文件、并验证密码是否与当前加载的软件相匹配(PASS)。
然后将新软件"TEST_V1.1.txt"被编程到 MSP430 (PASS)中。
然后、验证(存储器检查)阶段发生(失败)、密码检查失败。
CRC 计算
我使用在线 crccalc 工具计算新旧密码的预期 CCITT CRC。
V1.0 (旧)密码= 0xA366
V1.1 (新)密码= 0xFB55
结论
我认为 UniFlash 工具使用提供的密码文件数据对照当前加载的软件进行检查(OK)、但也使用它来检查正在加载的新软件(不正常)。
这部分基于处于"详细"模式时 UniFlash 的控制台输出：
