[参考译文] TMS570LS3137：无法在分配的闪存的末尾访问(读取)某些地址

您好、Jose、

您能否共享您的链接器 cmd 文件和项目中定义的 const？  

我无法完全共享 CMD 或项目代码。   在进一步调试这个问题时、我注意到 这个问题只有在我们在代码中启用闪存 ECC 后才会出现。

我们松散地关注 HALCoGen 4.07.01代码初始化。  在 sys_startup.c 中、在_c_int00早期、我们调用 _coreEnableFlashEcc_：

 在执行第320行之前、我们仍然能够访问该 存储器：

执行该行后、我们立即失去访问权限。

向0x7FFF8写入数据时、ECC 值是否被编程？

请检查0xF0400000 + 0x7FFF8/8处的 ECC 值

是的、似乎对该值进行了编程。

在启用 ECC 之前：

以下为：

您好、Jose、

我计算了0x7FFE8、0x7FFF0、0x7FFF8和0x80000处数据的 ECC 值

0x7FFE8处数据的 ECC 值为0x7F -->它与屏幕截图中的 ECC 相同(0xF040FFFD)  

0x7FFF0处数据的 ECC 值为0x8A ->它与屏幕截图中的 ECC 相同(0xF040FFFE)  

0x7FFF8处数据的 ECC 值为0x24 ->它不同于屏幕截图中的 ECC (0x05)(位于0xF040FFFF)

0x80000处数据的 ECC 值为0x5D -->它与屏幕截图中的 ECC 相同(0xF0410000处)

不知道这是怎么可能的，但是你是100%正确的！！

我们使用 Intel hex 文件刷写软件、以便按照 您的建议手动将地址0xF040FFFF 中的 ECC 代码从0x05修改为0x24、并确保我现在可以访问地址0x7FFF8中的数据。

我们的 CMD 文件中有如下所示的内容：

...
MEMORY
{
...
    MEMORY_NAME (R) : origin=0x0007FFC0 length=0x00000040 vfill=0xFFFFFFFF
...
    MEMORY_NAME_ECC : origin=0xF040FFF8 length=0x00000008 ecc={ input_range=MEMORY_NAME, algorithm=eccalgo, fill=true }
...
}
ECC
{
eccalgo : address_mask=0x003ffff8 hamming_mask=R4 parity_mask=0x0C mirroring=F021
}
...
SECTIONS
{
...
    .sectName : palign (32), {} > MEMORY_NAME
...
}

我们从未遇到过错误计算 ECC 代码的问题。   这种错误的原因可能是什么？

您的 CMD 文件对我来说看起来很好。

最好在 CMD 文件中使用 palign (32)。 Palign (32) 告诉链接 器将输出段.sectName 放置在位于32字节边界上的地址、并确保段的大小是32字节的倍数、填充空间(此段中未使用的空间)用零(默认值)填充。 这将避免 在高速缓存控制器捕捉到仅部分填满数据或代码的行时出现 ECC 错误。

您是否可以尝试将.sectName 分配给 FLASH0而不是 memory_name、并注释掉 MEMORY_NAME、MEMORY_NAME_ECC 在 MEMORY｛..｝中的位置？

存储器
｛
    引导程序(X)：origin=0x00000000 length=0x00000020 fill =0xFFFF
    FLASH0 (RX)：origin=0x00000020 length=0x001FFFE0 vfill = 0xffffffff
(笑声)

    ECC_VEC (R)：origin=(0xf0400000+(start (vectors)>>3)) length=( size (vectors)>>3)
             ecc=｛algoL2R5F021、input_range=vectors｝

    ECC_FLASH0 (R)：origin=(0xf0400000 +(start (FLASH0)>> 3)) length=(size (FLASH0)>> 3)
             ecc=｛algoL2R5F021、input_range=FLASH0｝

(笑声)  

｝

部分
｛
(笑声)
。   sectName：palign (32)，{}> FLASH0
(笑声)
｝

我尝试按照您的建议更改 CMD、我可以访问该符号。 代码正在进行开发、因此数据现在有所不同：

不过，这个问题似乎仍然影响到原来的地址，而且似乎已经扩散到其他地址。

我注意到 、当运行指令以启用闪存时、0x7FFFFC 中的数据从0xC... 到0xD...  其他地址中的数据也发生了类似的情况、这可能是显示/调试器类型的问题、因为闪存当然不能更改。

我们需要将符号放置在它最初的地址。 为什么生成十六进制文件时 ECC 计算失败？

如果使用*。out 文件而不是 hex 文件、您是否会遇到相同的问题？

我们按照您的建议尝试刷写输出文件、但出现错误：

您好、Jose、

输出文件由计算 ECC 的链接器 cmd 文件生成。 我不确定链接器在0xFFF8处生成的 ECC 为何不正确。 您能否将 MEMORY_NAME (R)的 VFILL=0xFFFFFFFF 替换为 fill=0xFFFFFFFF？  您可以共享链接器 CMD 文件吗？

如果您在加载期间使用 CCS 生成 ECC、问题是否也存在？