Other Parts Discussed in Thread: UCD90160A
器件型号： UCD90160A
我们现场有一款产品、正在尝试为 UCD90160A 实现一个稳健的现场更新过程、以控制器件的所有电源轨（这意味着更新失败会使器件砖化）。 我们目前使用 Fusion 的“数据闪存脚本“导出来对器件进行制造编程、并且为器件编写了标称编写和测试的应用程序代码、用于解析相同的数据闪存脚本并更新 UCD。 应用程序代码通过读取包含 MFR_REVISION 寄存器的数据闪存部分来确定当前版本（我们从 0x018820 读取 16 个字节；LENGTH 和 MFR_REVISION 寄存器是其中的前 13 个字节，我们可以告诉大家。） 这一切名义上都有效、但一种边缘情况除外：在某些（极少数）情况下、可以想象 I2C 总线故障或器件软件问题会阻止更新成功完成、而如果所有重试均失败、则回退是对器件的处理器进行软复位、这可能会解决问题。 这会使 UCD 在其当前配置下运行、但可能会在数据闪存中存储不一致或部分配置。 但是、由于我们的固件更新过程仅检查 0x18820 处的闪存、并且该闪存写入数据闪存脚本的相当早、因此可能会发现问题并导致器件崩溃。
在初始尝试修复此问题时、我手动修改了数据闪存脚本、以在所有其他写入和验证读取之后将一次闪存写入（在 0x018820 的 MFR_REVISION 空间中有 4 个字节）移动到脚本末尾。 这似乎是有效的,但只有当编辑是非常具体和有针对性的。 当遇到其他编辑数据闪存脚本的尝试时、会出现错误或 UCD 无法加载固件、并且感觉某些文档有些不一致、因此我想澄清以下几点：
- 像我尝试的那样以非顺序方式写入数据闪存是否可以接受？ 例如、写入整个闪存、但跳过中间的一个 4 字节块、然后读回以进行验证、然后在中间写入最后一个 4 字节块。
- UCD 编程指南 (slua815b) 的第 3.3 部分指示、对于 UCD90160A、数据闪存的有效地址范围为 0x18800 - 0x18DFF。 但是、导出的数据闪存脚本包含 0x18DFF 以外的地址、一个文件中最多为 18EFC、另一个文件中最多为 18FFC；尝试从脚本中手动删除高于假定有效范围的写入会导致错误。 在 MFR_REVISION 空间中仅更改一个或两个字节似乎会导致脚本的此区域发生许多更改。 配置数据的实际有效地址范围是多少/需要多少？
- Fusion 工具（2023 年 10 月推出的版本 7.10.1；似乎是最新版本）在查看数据闪存页面时、表示数据闪存校验和为 0x18E24 - 0x18E27、但这里的值始终为 0xFFFFFFFF 或 0x00000000（这超出了上述假定的配置数据有效范围）。 从数据闪存脚本中可以看出、CRC 区域似乎实际上可能在 0x18DE8 左右、或者在该更高空间中的某个位置。 如果实际数据闪存 CRC 位于常量位置、它位于何处？ （请注意，我理解它是静态计算的，并不反映数据闪存的当前状态；但是，与 MFR_REVISION 寄存器相比、我们使用它作为我们的版本哈希值来进行固件比较、尤其是在编程过程结束时写入得晚/晚的情况下。）
TL；DR 的目的是尝试使用数据闪存脚本现场更新 UCD90160A、我们的更新代码需要检测和处理 UCD 数据闪存因先前中断更新而部分不一致或无效的情况。 我们当前在 0x018820 从数据闪存读取 MFR_REVISION 的方法并不充分、因为在该点之后中断的更新看起来会成功、但实际上是使器件砖化。 我正在尝试评估对闪存脚本序列和/或更新过程的修改、以提高更新的可靠性。
