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.
https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1239364/tms320f2800157-ecc-is-not-same
大家好、
客户有问题需要您的帮助：
执行 uniflash 以读取控制板上的存储器操作、输出.out 文件、并将生成的文件写入另一个相同的控制板以进行完整性验证。 发现两者的 ECC 不同、其他的相同、而另一个相同。 处理十六进制文件,结果是一样的,如何解决?
您能帮助检查这个问题吗？
谢谢。此致、
本
尊敬的 Ben：
能否确认我的理解是否正确？
1.执行 uniflash 以读取控制板上的存储器操作、并输出.out 文件。
2.将生成的.out 文件写入同一控制卡并检查 ECC。
3、第1步的 ECC 与第2步的 ECC 不匹配。
4.执行 uniflash 以读取控制板上的存储器操作、并输出.hex 文件。
5. 将生成的.hex 文件写入同一控制卡并检查 ECC。 ECC 不 匹配。
此致、
拉杰什怀特
您好、Rajeshwarm：
是的、回答正确。
针对在闪存主阵列的64位边界上对齐的每一个64位数据计算一个8位 ECC 值。 相应64位数据的地址也包含在 ECC 计算中。
1. 使用生成的.out 文件或.hex 文件对控制卡进行编程后、闪存主阵列数据是否匹配？
2.在使用 Uniflash 写入控制卡时、 勾选了自动 ECC 生成的复选框？
如果已勾选、则闪存 API 会计算用户提供的地址(在64位存储器边界上对齐)和相应64位数据的 ECC。 在使用该模式时、API 对计算出的 ECC 和主阵列数据进行编程。
3.编程成功后验证闪存吗？
匹配。
2.选中或取消选中 Uniflash 自动 ECC 生成的复选框、校验和中的 ECC 与原始控制卡中校验和的 ECC 不同、且两个选中的 ECC 相同。
3.在验证校验和的完整性时、闪存、OTP 和 OTP ECC 是相同的、但 ECC 不同。
我会检查一下、然后回复给您。
我的客户遇到了同样的问题,希望您的回复,谢谢!
Ben、Bruce、
用户 从 Uniflash 下载闪存内容时、可能下载的是某个存储器范围(或整个闪存范围)、而不仅仅是初始化的段。 因此、当他们对镜像进行重新编程(任何格式)时、即使已擦除的位置的0xFFFF 也可能已经被编程(而不仅仅是已初始化的段)。 这意味着、ECC 即使对于已擦除的位置的数据0xFFFF 也已进行了编程。
只要他们在执行应用程序时没有遇到 ECC 错误、就应该没有问题。
瓦姆西
