Other Parts Discussed in Thread: UNIFLASH
对控制板进行uniflash读取memory操作,并输出.out文件,并把生成的文件写到另外一个相同的控制板上面,进行完整性验证,发现两者的ECC不同,其他的相同,并对其他Hex文件进行操作,结果相同,如何解决?
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.
对控制板进行uniflash读取memory操作,并输出.out文件,并把生成的文件写到另外一个相同的控制板上面,进行完整性验证,发现两者的ECC不同,其他的相同,并对其他Hex文件进行操作,结果相同,如何解决?
你好,请确认下我的理解是否正确?
1、在控制板上执行u niflash读取内存操作,输出.out文件。
2. 将生成的.out 文件写入同一张控制卡并检查ECC。
3. 第 1 步的 ECC 与第 2 步的 ECC 不匹配。
4、在控制板上进行uniflash读取内存操作,输出.hex文件。
5. 将生成的.hex 文件写入同一张控制卡并检查ECC。ECC 不匹配。
8 位 ECC 值根据闪存主阵列中在 64 位边界上对齐的每个 64 位数据计算。相应的64位数据的地址也包含在ECC计算中。
1. 使用生成的.out文件或.hex文件对控制卡进行编程后,Flash主数组数据是否匹配?
2. 使用 Uniflash 写入控制卡时, Auto ECC Generation 的 check_box是否被勾选?
如果选中,则 Flash API 会计算用户提供的地址(在 64 位内存边界上对齐)和相应的 64 位数据的 ECC。使用此模式时,API 将计算出的 ECC 与主阵列数据一起编程。
3、烧录成功后是否验证Flash?
你好,参考下工程师的回复:
When the users downloaded the flash contents form the Uniflash, they might have downloaded for a memory range (or the entire flash range) and not just the initialized sections alone. Hence, when they reprogram that image (any format), even the erased locations' 0xFFFF might have got programmed (and not just the initialized sections). This means, ECC got programmed even for the erased locations' data 0xFFFF.
As long as they don't get an ECC error while executing the application, they should be fine.