主题中讨论的其他器件：C2000WARE
下面是这些器件的闪存 ECC 用法的常见问题解答：TMS320F28M35x、TMS320F28M36x、TMS320F2837xD、TMS320F2837xS、TMS320F2807x、 TMS320F28004x、TMS320F28002x、TMS320F2838x。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.我们是否需要对闪存的 ECC 进行编程？
答案。 是的、必须对闪存和 OTP 的 ECC 进行编程。 复位时启用 ECC 检查。 因此、如果未对 ECC 进行编程、则会发生 ECC 错误。 双位 ECC 错误将导致 C28x 上的 NMI 和 M3/M4上的总线故障。
2.即使我的应用程序禁用了 ECC 检查、我们是否也需要对 ECC 进行编程？
答案。 BootROM 代码不会禁用 ECC 检查。 因此、即使用户应用在其代码中的某个点禁用 ECC、引导 ROM 跳转到应用程序代码时仍会出现 ECC 错误、因为 ECC 仅在用户应用程序的稍后阶段被禁用。 这将导致一个连续复位周期、因此应用代码永远不会被执行。
3.在对闪存或 OTP 进行编程时、我们是否需要禁用 ECC 检查？
答案。 通常、在闪存或 OTP 编程期间无需禁用 ECC 检查。 但是、TI 为 TI-OTP 编程的 ECC 在 TMS320F28M35x Rev0和 TMS320F2837xD 器件中不正确–因此、TI 发布了一个勘误项、要求在对闪存或 OTP 进行编程时禁用 ECC 检查。 您可以在闪存编程结束后重新启用 ECC 检查。
4.是否必须启用闪存/ OTP 读取或提取的 ECC 检查？
答案。 这取决于您的应用的安全要求。 如上述常见问题解答中所述、启用 ECC 检查会针对单位错误(达到阈值时)和不可纠正错误的 NMI/总线故障生成中断。 因此、TI 建议启用 ECC 检查。 请注意、无论启用还是禁用 ECC 校验、都必须对 ECC 进行编程。
5.启用或禁用 ECC 检查是什么意思？ 使用闪存 API 对闪存/ OTP 进行编程时、是否与使用 Fapi_AutoEccGeneration 相同？
答案。 不、它们是不同的。 在使用闪存 API 对闪存/ OTP 进行编程时、您可以使用 Fapi_AutoEccGeneration 来生成 ECC 并对其进行编程。 ECC 校验与闪存/ OTP 的读取路径相关。 启用后、SECDED 逻辑将检查从闪存或 OTP 提取/读取的代码/数据中是否存在任何单个或不可纠正的错误。
6.如何启用或禁用 ECC 检查？
答案。 您可以使用 ECC_ENABLE 寄存器。 检查 TRM 的描述。
ECC 是否能捕获两个以上的位错误？
答案。 它最多只能捕获两个位错误。
SECDED 逻辑是否可以纠正双位错误？
答案。 不，不能。 它只能在将数据提供给 CPU 之前纠正单个位错误。
9. SECDED 逻辑是否也纠正了闪存/ OTP 中的单一位错误？
答案。 不可以、它会将校正后的数据提供给 CPU、但它不会纠正闪存中的错误。 如果必须纠正闪存中的错误、用户应用必须擦除和编程闪存。
10. FMC 是否也会捕获 ECC 空间中的错误？
答案。 是的、SECDED 逻辑使用64位对齐地址以及相应的64位数据和8位 ECC 值来评估从闪存/ OTP 读取的数据的正确性。
11.我们能否读取 ECC 空间来捕获错误？
答案。 否、读取 ECC 空间不会导致 SECDED 逻辑捕获错误。 应用程序应读取主阵列闪存/ OTP 以捕捉错误。
12.调试器读取是否经过 SECDED 逻辑并得到校正？
答案。 否 调试器按原样显示闪存数据(包括错误)。 调试器读取不会触发 SECDED 逻辑来评估 ECC。
13.启用 ECC 检查后、是否有 ECC 未针对闪存/ OTP 读取进行评估的情况？
答案。 是的、当所有64位数据和相应的8位 ECC 值全部为1或全部为0时、SECDED 逻辑跳过 ECC 评估。 此外、不会针对 OTP 中的 DCSM 链接指针位置评估 ECC。 此外、在 FMC 中启用预取时、避免使用闪存组的最后128位–这是为了避免 ECC 错误。
14.我们可以使用 ECC 空间来处理应用程序代码/数据吗？
答案。 否 闪存 ECC 空间不允许提取数据。 TI 建议始终对 ECC 进行编程，因此该空间不能用于应用程序代码或数据。
我们可以得到 ECC 算法吗？
答案。 它在 C2000Ware 中提供的闪存 API 参考指南(针对每个器件)的附录中提供。
16.单位闪存 ECC 错误的建议阈值是多少？
答案。 这取决于应用的需求。 如果用户应用程序不能容忍任何错误，则当然必须使用0的阈值。 此外、这些器件中使用的闪存技术非常可靠。 根据现场经验数据、未报告此问题的故障。 因此、可以使用0阈值。 但是、对于某些 C2000器件、有一个勘误表(建议 C28x 闪存：单位 ECC 错误可能会导致对单位错误中断服务例程的无限调用)要求用户应用将阈值设置为大于或等于1的值。 有关更多详细信息、请查看勘误表。
17. FMC 中有多少个 SECDED 模块？
答案。 有两个 SECDED 模块。 闪存读取总线宽度为128位(对齐)。 有一个专用的 SECDED 模块、用于分别评估低64位和高64位的 ECC。
18.何时对从闪存读取/提取的数据进行 ECC 评估？
答案。 当从闪存执行读取或提取操作时、以及在将数据放入闪存预取缓冲器和缓存之前、ECC 会被评估。
19. ECC 检查是否也可用于缓存和预取缓冲器？
答案。 否
使用 ECC over CRC 有什么好处？
答案。 两者都有各自的优缺点。 CRC 可在整个闪存映像上以固定的间隔完成–这需要 CPU 带宽。 当闪存被访问时、针对闪存的每次读取或提取对 ECC 进行分析–这不占用 CPU 带宽。 在这种情况下、即使是整个闪存组也可以在 ECC 启用的情况下定期读取、以便在需要时捕获任何错误。 但是、ECC 最多可以捕获两位错误。
21.如何计算 ECC？
答案。 针对在闪存主阵列中的64位边界上对齐的每个64位数据计算一个8位 ECC 值。 相应64位数据的地址也包含在 ECC 计算中。 用于 ECC 计算的算法在闪存 API 参考指南的附录中提供。
22.如何计算要编程的 ECC？
答案。 当在应用程序中使用闪存 API 对闪存进行编程时，您可以将“Fapi_AutoECCGeneration”作为程序函数的编程模式参数传递。 使用此模式时、API 会计算用户提供的地址(在64位存储器边界上对齐)和相应的64位数据的 ECC。 使用此模式时、API 会对计算出的 ECC 以及主数组数据进行编程。 如果不是用于程序操作，用户应用程序也可以使用闪存 API 库中提供的 Fapi_calculateEcc()函数计算 ECC。 请注意、此函数使用 FMC 中的 SECDED 硬件逻辑来计算 ECC。 请注意、当用于 F28M35x、F28M36x、F2837xD、F2837xS 和 F2807x 器件中的 C28x 时、此函数需要一个左移(1位位置)地址。 对于其余器件、API 在计算 ECC 之前负责将地址左移。
如果用户希望在主机器件而非目标 MCU 上计算 ECC、则可以使用闪存 API 指南附录中提供的 ECC 计算算法。
使用 TI 闪存工具时，提供了“AutoEccGeneration”选项的设置，启用时(默认情况下启用，除非用户禁用)，将在使用 API 对闪存/OTP 中的可执行文件进行编程时使用 Fapi_AutoEccGeneration 选项。 CodeSkin、Elprotronic、数据 I/O 等第三方工具也使用 Fapi_AutoEccGeneration 模式来生成和编程闪存映像的 ECC。
TI 编译器工具提供了在链接步骤生成 ECC 的选项。 这需要在链接器命令文件中使用特殊的 ECC 限定符和指令。 使用这些选项、可以在可执行映像中附加闪存映像的 ECC。 当链接器生成的 ECC 是可执行映像的一部分时，用户应确保禁用 TI 闪存工具中的“AutoEccGeneration”选项，因为 ECC 已经是可执行映像的一部分。 当使用链接器生成的 ECC 选项时、有一种配置可以在所选位位置的所选地址/偏移处插入有意错误。 请参阅《TMS320C28x 汇编语言工具》用户指南和《M3/M4 ARM 汇编语言工具》用户指南的“链接器说明”一章中的“纠错码测试(--ECC 选项)”主题。
23.在链接器命令文件中使用 ECC 限定符和指令时、CCS 项目设置中是否有插入错误的规定？
答案。 是的、转到项目构建设置->构建-> C2000链接器->高级选项->链接器输出。
您将注意到以下选项：
(i)--ecc：data_error 选项
•在给定地址插入错误(地址可以在主数组或 ECC 空间中)
•若要在 ECC 空间中插入错误、您应该知道 ECC 地址
•输入要插入错误的地址(或 symbol+offset)、PAGE、要插入错误的16位位位掩码
(ii)--ecc：ecc_error 选项
•在与给定的主阵列地址相对应的 ECC 内存中插入错误
•如果在 ECC 空间中插入错误，则不需要 ECC 地址
•输入要在其对应的 ECC 内存位置、页、位掩码(宽度为8位)插入错误的主数组地址。
24.能否单独对主阵列数据和 ECC 内存进行编程？
答案。 您可以单独对主阵列数据和 ECC 进行编程。 但是、每个64位数据字和相应的 ECC 字在每个写入/擦除周期只能被编程一次。 因此、请注意、必须同时对所有64位数据(在64位边界上对齐)进行编程。 此外、ECC 的所有8位必须同时编程。 如 API 参考指南中所述、即使将数据和 ECC 编程在一起也是如此-主阵列闪存编程必须与64位地址边界对齐、并且每个64位字在每个写入/擦除周期只能编程一次。
对于 DCSM OTP、编程必须与128位地址边界对齐、并且每个128位字只能编程一次。 例外情况如下：
–DCSM OTP 中的 DCSM Zx-LINKPOINTER1和 Zx-LINKPOINTER2值应一起编程、并且可以按照 DCSM 操作的要求、一次编程1位。
–DCSM OTP 中的 DCSM ZX-LINKPOINTER3值可以按照 DCSM 操作的要求一次编程1位。
25.为什么不应该为链路指针位置对 ECC 进行编程？
答案。 只要 ZoneSelect 块被更新、就需要一次对1位的链路指针位置进行编程。 一旦 ECC 被编程到任何64位数据位置、这个位置就不能被再次编程(即使对1至0进行编程)、这是因为 ECC 值将针对新数据值发生变化、并且在不进行擦除操作的情况下也不能改变 ECC 值。 因此、不应针对链路指针位置对 ECC 进行编程、以便允许 ECC 进行后续更新。
26.如果我使用 Fapi_AutoEccGeneration 或 Fapi_DataAndEcc 或 Fapi_EccOnly 模式对链接指针位置进行编程、闪存 API 是否会失败？
答案。 否、API 将使用 Fapi_DataOnly 模式来避免针对链接指针位置对 ECC 进行编程。 用户必须在这里小心操作–当用户应用程序或闪存工具将链接指针地址作为程序操作的起始地址发送时、闪存 API 只对数据进行编程、而不对 ECC 进行编程。 因此、当为程序操作提供给 API 的地址为链接指针地址时、提供给 API 的数据的长度(字/字节的数量)应确保程序的起始地址加上长度不应超过链接指针位置。 否则、闪存 API 也会跳过针对非链路指针位置的 ECC 编程。 当应用程序从未对 ECC 进行编程的位置读取或获取数据时、这将导致 ECC 错误。 因此、在应用中、应将链接指针保留在单独的结构/段中、以便当可执行映像由闪存工具进行流式传输时、只有与链接指针相关的地址才会获得 Fapi_DataOnly 模式、以便 API 进行编程。
27.我们如何向 CPU 通知 ECC 错误？
答案。 确保通过在 ECC_ENABLE 寄存器中写入0xA 来启用 ECC-Check。 这是该寄存器的复位值。 这将使 SECDED 逻辑能够评估从闪存获取/读取的数据的有效性。 配置 PIE 以允许来自 SECDED 的 FLASH_corrected_error (INT12.11)中断。 不可纠正的错误(双位错误或地址位错误)将通过 C2000器件中的 NMI/总线故障(C28x/ARM)发出通知。
28.当 SECDED 逻辑捕获到单个位错误时、会记录什么所有信息？
答案。 请在 TRM 的‘Flash and OTP Memory (闪存和 OTP 内存)一章中查看“Single-bit Data Error (单位数据错误)”主题。
29.当 SECDED 逻辑捕获到不可纠正的错误时、会记录什么所有信息？
答案。 请在 TRM 的‘Flash and OTP Memory (闪存和 OTP 内存)一章中检查“Uncorrectable Error (不可纠正的错误)”主题。
30、当捕捉到单个位错误时、为什么我的应用滞留在单个位错误 ISR 的无限循环中？
答案。 请确保错误阈值已配置为大于等于1的值。 在某些设备中，‘0’的阈值可能会导致此行为。 请查看勘误咨询“闪存：单位 ECC 错误可能会导致对单位错误 ISR 的无限调用”。
31.如何确保 SECDED 逻辑块在运行时正常工作？
回答：应用程序可以使用 ECC 测试模式，在 TRM 的‘闪存和 OTP 存储器”一章的“SECDED 逻辑正确性检查”主题中对此进行了说明。 在此模式下、应用程序可以在 ECC 测试模式寄存器(提供给地址、数据和 ECC)中插入错误、并查看 SECDED 逻辑块是否能够捕获错误。 当这个测试模式被启用时、闪存被旁路并且到闪存地址的任何读取将被写入 ECC 测试模式寄存器。 ECC 测试模式寄存器中配置的地址、数据和 ECC 被发送到 SECDED 逻辑进行评估。 通过使用这种方法、用户应用程序可以在运行时检查 SECDED 逻辑、而无需在闪存存储器空间中实际插入错误。 请记住、应通过从 RAM 中执行代码来使用此模式、因为当启用此模式时、闪存会被绕过。
如果应用要求从直接闪存读取(而不是从 ECC 测试模式寄存器)中评估错误、则可以使用链接器 ECC 选项在闪存编程之前在闪存映像中插入错误。 请参阅《TMS320C28x 汇编语言工具》用户指南和《M3/M4 ARM 汇编语言工具》用户指南的“链接器说明”一章中的“纠错码测试(--ECC 选项)”主题。
对于在固件升级解决方案中使用闪存 API 的应用程序，闪存 API 具有 ECC 计算(Fapi_calculateEcc())函数，用于计算给定地址和数据的 ECC。 用户应用程序可以使用此值来计算 ECC。 可以根据应用的需要在数据和/或 ECC 中插入错误。 然后可以使用 Fapi_DataAndEcc 模式将修改后的数据和 ECC 编程为 Fapi_issueProgrammingCommand()的参数。
32。当使用 ECC 测试模式时、NMI 是否针对不可纠正的错误发生？
答案。 是、如果 NMI 已启用。
33.使用 ECC 测试模式时，单位错误是否会产生单位错误中断？
答案。 是的、如果中断被启用。
启用 ECC 测试模式后、我们是否需要为 SECDED 逻辑启用 ECC (ECC_ENABLE 寄存器)以评估 ECC？
答案。 否、即使 ECC 被禁用、SECDED 逻辑也会评估 ECC。
在 Concerto 中使用 ECC 测试模式时、插入错误后启用 ECC_TEST_EN 位时、为什么会连续发生单个位错误中断或 NMI？
答案。 ECC 测试模式、当被启用时、将在每个周期内持续评估测试模式寄存器的错误、因此、在 ECC 测试模式被禁用前、将持续发生单位错误中断和/或 NMI。 为了避免连续中断、在闪存单位错误 ISR 和 NMI ISR 中禁用 ECC 测试模式(ECC_TEST_EN = 0)。
在 F2837xD、F2837xS 和 F28004x 器件中使用 ECC 测试模式时、为什么我们同时具有 ECC_TEST_EN 和 DO_ECC_CALC 位？
答案。 ECC_TEST_EN 位通过将地址、数据和 ECC 从 ECC 测试模式寄存器路由到 SECDED 逻辑块来启用 ECC 测试模式。 DO_ECC_CALC 位触发 SECDED 逻辑、以在单个周期内评估 FADDR_TEST、FDATAx_TEST 和 FECC_TEST 寄存器中的地址、数据、ECC 错误。
37.使用由链接器生成的 ECC 是否比使用 AutoEccGeneration 有任何优势？
答案。 这两种方法的目的都是为闪存/ OTP 映像生成 ECC。 AutoEccGeneration 使用简单、因为用户不必对其链接器 cmd 文件进行任何更改即可使用它。 但是、当 ECC 作为链路步骤的一部分生成时、其优势很少：
(i)某些安全应用可能需要在不使用目标 MCU 中的 SECDED 硬件逻辑的情况下生成 ECC。 对于此类应用、ECC 生成源和 ECC 评估源应该不同。 链接器生成的 ECC 满足此要求、因为 ECC 由编译器在链接步骤期间生成、而不是由 MCU 中的 SECDED 逻辑生成。
(ii)一些客户希望向第三方提供完整的应用映像、以便对其器件进行编程。 在这种情况下、客户希望包括 ECC 空间在内的整个映像的校验和。 链接器生成的 ECC 满足此要求、因为 ECC 值也是可执行映像的一部分。 一旦第三方在闪存中对映像进行编程、客户就可以运行整个闪存映像的校验和。
(iii)除了这些之外、链接器还提供了在闪存/ECC 空间中插入错误的选项、以便应用程序可以读取这些错误插入的地址、以在运行时检查 SECDED 逻辑的运行状况。
38.使用由链接器生成的 ECC 是否有任何缺点？
答案。 使用由链接器生成的 ECC 时、编程时间更长、因为主阵列和 ECC 空间是单独编程的。 使用 AutoEccGeneration 时，会同时对 MainArray 和 ECC 空间进行编程。 此外、为了启用由链接器生成的 ECC、链接器命令文件需要进行一些更改。
39.在链接步骤期间、为了生成 ECC、我们需要在链接器命令文件中进行哪些更改？
答案。 在更改链接器命令文件时、应遵循以下步骤、以便能够在链接步骤期间生成 ECC 并将 ECC 附加到可执行文件中、作为单独的部分。
(i)为在链接器命令文件的存储器段中定义的每个闪存存储器范围定义 ECC 存储器范围。 例如、请参阅下面的示例链接器命令文件内容。 FLASH_A 是闪存扇区 A 存储器范围。 相应的 ECC 存储器范围为 FLASH_A_ECC。 所有闪存/ OTP 范围的 ECC 存储器范围的定义方式应该相同。 请注意、所有存储器范围应该是128位的倍数(因为 每个128位对齐数据的 ECC 都反映在 ECC 存储器映射的一个地址上)。
存储器
｛
第0页：/*程序内存*/
Flash_A ：origin=0x80000、length=0x2000、vfill = 0xFFFF
Flash_B ：origin=0x82000、length=0x2000、vfill =0xFFFF
第1页：/*数据存储器*/
Flash_C ：origin=0x84000、length=0x2000、vfill =0xFFFF
Flash_D ：origin=0x86000、length=0x2000、vfill =0xFFFF
FLASH_A_ECC ：origin=0x1080000、length=0x400、ECC =｛/* ECC 限定符*/
INPUT_RANGE = FLASH_A、 INPUT_PAGE = 0、 算法= C2000_Algo、 填充 = true ｝ /* ECC 限定符的末尾*/
FLASH_B_ECC ：origin=0x1080400、length=0x400、ECC =｛
INPUT_RANGE = FLASH_B、 INPUT_PAGE = 0、 算法= C2000_Algo、 填充 = true ｝
FLASH_C _ECC ：origin=0x1080800、length=0x400、ECC =｛
INPUT_RANGE = FLASH_C、 INPUT_PAGE = 1、 算法= C2000_Algo、 填充 = true ｝
FLASH_D_ECC ：origin=0x1080C00，length=0x400，ECC ={
INPUT_RANGE = FLASH_D、 INPUT_PAGE = 1、 算法= C2000_Algo、 填充 = true ｝
}/*内存结束*/
部分
｛
/*将段分配给内存区域*/
}/*段末尾*/
ECC ｛
C2000_Algo： address_mask = 0x1FFFFC
奇偶校验掩码= 0xFC
镜像= F021
} /* ECC 指令的末尾*/
(ii)除了 origin 和 length 等存储器属性外，您可能还注意到 ECC 存储器范围定义中有一个“ECC”限定符。 链接器需要这样做才能意识到它是为特定闪存主阵列定义定义定义的 ECC 存储器范围。
(iii) ECC 说明符中的第一个参数是“input_range”-这应该指向给定 ECC 内存范围的相应闪存主阵列内存范围。 例如、FLASH_A 是 FLASH_A_ECC 存储器的输入范围。
(iv) ECC 限定符中的第二个参数是"input_page"-这应该指向给定 ECC 内存范围对应的闪存主阵列内存范围的页。 例如、FLASH_A 在 PAGE 0中定义。 因此、FLASH_A_ECC 的 INPUT_PAGE 应为0。
(v) ECC 限定符中的第三个参数是“algorm”-这是一个您可以选择的名称(可以是任何名称)，并在以后使用 ECC 指令在命令文件中定义(在段定义之后)。 在上面的示例中、选择 ALGO 的名称作为 C2000_ALGO。
(vi) ECC 限定符中的第四个参数是"fill (填充)"–如果选择"true"、链接器将为输入范围的初始化数据中的空洞生成 ECC 数据。 默认值为"true"。 使用 input_range 中的“vfill”属性指定空穴中填充的数据。 我们建议您为 C28x 使用0xFFFF (为 ARM 使用0xFF)、因为处于擦除状态的闪存的默认值都为1。 请注意，假定提供的“vfill”值为空穴生成 ECC，但“vfill”值(此处为0xFFFF)不会使其进入可执行输出文件。 这将有助于减小可执行文件的大小。 如果您不想为孔洞生成 ECC，以便以后可以在运行时使用该内存，则可以为 ECC 限定符的“fill”参数选择“false”输入。 请注意，即使在“fill = false”的情况下，也应提供“vfill”值(建议为0xFFFF)以填充任何不完整的64位数据(在64位存储器边界上对齐)。 如果在这种情况下没有提供“vfill”值，编译器将为64位数据中的不完整数据假定0。 如果出现“fill=false”情况，则提供的“vfill”值将不会用于填充完全未使用的任何64位孔洞。 有关 VFILL 用法的更多详细信息，请参阅《C28x 汇编语言工具》用户指南《C28x 用户指南》和《ARM 汇编语言工具》用户指南《M3/M4的链接器说明》一章中的“在内存映射中使用 VFILL 说明符”主题。
(vii)如上述给定链接器命令文件示例末尾所示，应向链接器命令文件添加顶级“ECC”指令，以便为生成 ECC 数据的算法提供参数。 算法的名称可以是任何、但应与 ECC 限定符中指定的名称相匹配。 在上面的示例中、算法的名称被选为 C2000_Algo。 为算法提供的参数应如示例中的此处所示、用户不应修改它们。 它们是 ECC 算法的参数、编译器使用这些参数来生成 ECC 值。
(VIII)在链接器命令文件中使用 ECC 限定符和 ECC 指令时、编译器将自动生成 ECC 并将其作为可执行输出中的单独数据段附加。
(IX)请注意、在链接器命令文件中使用 ECC 限定符和 ECC 指令时、应禁用闪存工具中的 AutoEccGeneration。
40.如何使用链接器 ECC 选项在闪存可执行文件输出中插入错误？
答案。 请参阅《TMS320C28x 汇编语言工具》用户指南和《ARM 汇编语言工具》用户指南的“链接器说明”一章中的“纠错码测试(--ECC 选项)”主题。 请注意、链接器生成的 ECC 程序仅在 F28004x、F2838x、F28002x 及更高版本上受支持。 F28M35x/36x 和 F2837x/F2807x 器件不支持该功能。
41.为什么在 C2000Ware 示例中提供的链接器 cmd 文件中使用 align 指令(align (x))？
答案。 Fapi_AutoEccGeneration 模式(其中一种闪存 API 编程模式)对闪存中提供的数据部分进行编程、并自动生成 ECC。 针对64位对齐地址和相应的64位数据计算 ECC。 未提供的任何数据(在给定的64位对齐存储器内)都被视为0xFFFF。 请注意、当编写一个定制编程实用程序时、会将此实用程序流式传输到代码工程的输出文件中、并将每个段一次编程到闪存中、这会产生实际影响。 如果一个64位字跨越多个段(即、包含一个段的末尾、以及另一个段的起始部分)、那么在对第一个段进行编程时、不能为64位字中缺少的数据假定0xFFFF 的值。 当您对第二部分进行编程时、您将无法对第一个64位字的 ECC 进行编程、因为它已经(错误)使用假定的0xFFFF 针对缺失的值进行计算和编程。 避免此问题的一种方法是在代码项目的链接器命令文件中以64位边界对齐链接到闪存的所有段(最好是128位对齐、因为大多数闪存编程器一次编程128位)。
以下是 C28x 的一个示例(对于 ARM、应使用 ALIGN (16))：
部分
｛
.text ：> FLASH，page=0，align (8)//此处 align (8)确保.text 段在128位对齐的内存地址*/上启动
.cinit：> FLASH、PAGE = 0、ALIGN (8)
.const：> FLASH、PAGE = 0、ALIGN (8)
.econst：> FLASH、PAGE = 0、ALIGN (8)
.pinit：> FLASH、page=0、align (8)
.switch：> FLASH、PAGE= 0、ALIGN (8)
｝
如果不对齐闪存中的段、则需要跟踪段中未完成的64位字、并将它们与完成64位字的其他段中的字组合在一起。 这将很难做到。 因此、建议在64位边界上对齐您的段(最好进行128位对齐、因为大多数编程器一次编程128位)。
42. ECC 映像是否附加到任何输出格式？
答案：不 仅.out 格式支持链接器 ECC 生成。 将.out 转换为十六进制格式时、十六进制工具不会附加 ECC 段。
--
Vamsi Gudivada
C2000系统软件工程
C2000培训小程序码
