您好，技术支持、
客户分享了 一个问题，即在启动时调用 sCheck_ExecuteStartupTests()，之后在执行 ECC 测试时会跳转到硬故障异常。
您能帮忙检查一下这一点吗？
MCU: S32K314
你好@marcuslim,
对于每个 sCheck 测试，都必须遵循 sCheck UM 章节中描述的所有条件： L1 CACHE ECC 测试
在这种情况下，很可能是内存部分的位置和适当的 MPU 设置有误，这对正确执行该测试非常重要。
更多详情，请参阅 sCheck UM 章节： 内存分配（将内存分配到具有正确的可缓存或不可缓存 MPU 属性的部分至关重要）
，您还可以在 SAF 演示示例中探索链接器文件和 MPU 设置。
亲切的问候，
Radoslav
嗨，拉多斯拉夫、
Cusotmer 将恩智浦示例中的 sCheck_ExecuteRuntimeTests() 替换为 sCheck_ExecuteStartupTests()，结果遇到了类似的错误。
能否请您明确说明我可以在哪里检查？
嗨 @marcuslim
不，你不能通过在专用的用于运行时测试的循环中替换 sCheck 启动测试来使用。
启动测试只应在应用程序启动过程开始时执行一次。
此外，SAF 演示示例不支持 K314，因此，如果您重复使用了某些链接器文件，它很可能不会遵循 K314 设备的内存映射，需要进行更新。
SAF 不容易内置，需要认真学习 sCheck 手册并了解软件功能安全概念。
亲切的问候，
Radoslav
嗨，拉多斯拉夫、
客户反馈：
不过，我们目前遇到了与 ECC 检查有关的问题。您可能已经注意到，恩智浦示例中也出现了类似的 ECC 检查问题。
内置SAF软件包非常具有挑战性，因此，我们将感谢恩智浦专家在这方面的支持。
您能否就我们需要遵循和验证的与链接器相关的具体要点或要求提出建议，以便正确内置 ECC 检查？
提前感谢您的帮助。
你好，Marcus，
，所有信息都应该从 sCheck UM 中清楚地了解到，至少我通常不会遇到这类问题，所以 SAF 团队认为 sCheck UM 在这方面是清楚的。
您能否询问客户 sCheck UM 到底有哪些不清楚的地方，以便我们改进？
谢谢，
Radoslav
嗨，拉多斯拉夫、
客户将 *(.ramcode_no_cacheable) 从 int_sram_no_cacheable 移至 int_sram，结果运行正常。 如有任何意见，请随时提出。
根据 表 55.sCheck 模块中的 MemMap 部分,
以下部分必须放在特定的闪存区域中：
- s32_saf_const_flash_0
- → 代码闪存 0
- s32_saf_const_flash_1
- → 代码闪存 1
- s32_saf_const_flash_2
- → 代码闪存 2
- s32_saf_const_flash_3
- → 代码闪存 3
不过，在我的系统中，我使用的是 A/B 交换因此，在任何时候都只有 闪存 0 和 闪存 1 被应用程序激活/使用。
放置 s32_saf_const_flash_2 和 s32_saf_const_flash_3 和 32_saf_const_flash_3 可能会干扰未使用的闪存区域（例如，为其他闪存组或 OTA 更新预留的闪存区域）。
我的问题是
- 是否有办法配置 sCheck，使其只在 Flash 0 和 Flash 1 上执行测试？
- 或者 是否有安全的方法来测试所有四个闪存块（闪存 0-3），而不影响 A/B 交换使用的非活动库的内容？ 的内容？
嗨，拉多斯拉夫、
除了上一篇文章中提出的问题外，客户还分享说，在执行sCheck_ExecuteStartupTests和sCheck_ExecuteRuntimeTests 之后，系统始终报告同一组与 ECC 相关的错误：
- scheck_err_dcache_ecc_cm7_0
- scheck_err_icache_ecc_cm7_0
- SCHECK_ERR_ITCM_M7_0_ECC
- SCHECK_ERR_DTCM_M7_0_ECC
在每次测试执行过程中，这些错误都会反复出现。
能否请您协助我们调查并确定这种行为的根本原因？
敬上，
马库斯
嗨 @marcuslim，
将 *（.ramcode_no_cacheable）从 int_sram_no_cacheable 移至 int_sram 起作用可能有点巧合。
我怀疑如果客户将 HFNMIENA 设置为 0，则在触发信号时可能会造成麻烦。
请检查一下 MPU_CTRL.HFNMIENA 的值是多少。
如果该值为零，则已针对即将发布的 1.0.6 版本进行了以下修复：
[ASFT-19327] [sCheck] 不支持 Arm M7 HFNMIA - 恩智浦 JIRA
sCheck 闪存测试不能仅缩减为 Flash_0 和 Flash_1，但已对即将发布的 1.0.6 版本进行了更改，无需将特定的闪存部分放入链接器文件中，而是使用配置的闪存地址，其中地址的内容不会被修改，这也可以解决 A/B 交换客户的问题。
https://jira.sw.nxp.com/browse/ASFT-19738
此致，
拉多斯拉夫
你好@marcuslim
，我认为有一个共同的根源。
内存部分需要根据可缓存/不可缓存 MPU 属性正确放置，上一篇文章中提到的 HFNMIENA 位也会造成问题。
亲切的问候，
Radoslav
嗨，拉多斯拉夫、
客户尝试重新定位 *(.ramcode_no_cacheable)。 到 int_sram_noo_cacheable 而不是 内存 并将 HFNMIENA = 0。 此外，还对 MPU 进行了适当配置，以允许从不可缓存 RAM 区域执行代码。
经过进一步调查，发现在 sCheck_Tcm_RunEccTest 中的函数 sCheck_Tcm_MemTestEccCorrError 和 sCheck_Tcm_MemTestUncorrError 函数将被执行。
这两个函数都调用 sCheck_ErrRead(pParams,&result）。
但是，当 sCheck_Tcm_MemTestEccCorrError 成功完成、
scheck_tcm_memtestuncorrerRror 在 调用 scheck_errRead（PParams，& 结果）（附图中的第 1 点）时会 触发 HardFaul t， 系统随后卡在 BusFault 处理程序 （所附图像中的第 2 点） 中。
能否请您帮助调查一下这一点？
嗨 @marcuslim，
对不起我错了，你的 SAF 版本中的正确设置应为 HFNMIENA = 1，以避免在异常中更改 MPU 设置，这可能会进一步导致缓存之后刷新一些变化。这就解释了为什么 TCM correctable 可以通过，而 Uncorrectable 不能通过，因为它使用异常来测试正确的反应。
亲切的问候，
Radoslav
嗨，拉多斯拉夫、
客户反馈：
>>>>>>>>
配置HFNMIENA = 1 后，我发现sCheck_ExecuteStartupTests()可以正常运行。此时，我不再观察到任何与 ECC 相关的错误。我将进行额外的压力测试，以进一步验证这种行为。
但是，当调用 sCheck_ExecuteRuntimeTests() 并随后调用 sCheck_Tcm_MemTestUncorrError() 时，系统会在设置 INVSTATE（无效状态）标志的情况下触发信号 UsageFault 异常。
请问sCheck_ExecuteStartupTests()和sCheck_ExecuteRuntimeTests()之间是否存在任何设计上的差异或特定的使用条件，会导致这种行为？
此致，
马库斯
您好@marcuslim,
如果启用了 FPU，这可能表明存在参数问题，我们需要进一步调查。
您能否尝试禁用 FPU 并重新进行测试？
现在结果如何？
启用 FPU 后，能否在 Watch 窗口的异常跟踪中使用这些变量：
sCheck_ErrRead_ExceptionContext.bAbortFlag
sCheck_DetectedFaults[0]
并再次粘贴截图？
FCCU NCF_2 通道的配置反应是什么？
，
Radoslav。
嗨，拉多斯拉夫、
请在此提供所需的信息：
要点 1：禁用 FPU
- 同样的错误。
要点 2：启用 FPU
第 3 点：FCCU NCF_2 反应
此致，
马库斯
你好，马库斯、
最新截图显示，它产生的是内存管理故障，而不是使用故障（如原帖所示）。因此，我认为我们需要澄清我们面临的例外情况是什么。
请检查/共享 MPU 配置。
你能检查一下异常是否由"LDRD R0,R1,[R1]\n" 指令（来自 sCheck_Lib_ARMv7M.c 或其他指令）引起的吗？
亲切的问候，
Radoslav
嗨，拉多斯拉夫、
附上客户的 MPU 配置和链接器文件。他希望我们对其进行审查。
此致，
马库斯
嗨 @marcuslim，
我看到他们重复使用了 RTD 示例 systemInit () 中的 MPU 配置。
请注意，这只是 RTD 的短截线，未经验证，即使对于某些 RTD 驱动程序来说也可能不够，更不用说 SAF 了。
同样，对于链接器文件，我可以看到来自RTD链接器文件的来源，以及额外的SAF和SCST内存部分。
关于 MPU 配置，我强烈建议使用 RTD Platform 插件配置 MPU。
在 SAF 演示示例中，我们还提供了 K344 的 MPU 配置示例（不是 K314，但只需修改 TCM 的正确内存大小）。
但它也只是 SAF Demo 设置的示例代码（短截线），未经过验证的交付内容。
按照人工智能的要求，他们的 MPU 配置应该代表这种设置：
| 地区 | RBAR 地址 | 大小 | 类型/缓存政策 | 可共享 | 门禁系统 | 说明 |
|---|---|---|---|---|---|---|
| 0 | 0x00000000 |
覆盖整个地址空间（RASR =0x1004003F) |
强烈订购，无缓存 | 是 | 无访问 | 背景区域阻挡一切 |
| 1 | __INT_ITCM_START |
来自链接器 | 正常，无缓存 | 无 | RW/RW | 用于 CM7 的 ITCM |
| 2 | __ROM_CODE_START |
来自链接器 | 正常，WB/WA（内侧& 外侧） | 无 | RO/RO | 主程序闪光 |
| 3 | __ROM_DATA_START |
来自链接器 | 正常，WB/WA | 是 | RO/RO | 数据闪存 |
| 4 | 0x1B000000 |
8 KB (0x160B0019) |
正常，WB/WA | 是 | RO/RO | UTEST 地区 |
| 5 | __INT_DTCM_START |
来自链接器 | 正常，无缓存 | 无 | RW/RW | CM7 的 DTCM |
| 6 | __INT_SRAM_START |
来自链接器的大小 (__RAM_CACHEABLE_SIZE) |
正常，WB/WA | 无 | RW/RW | 可高速缓存 SRAM（禁用子区域 6 和 7） |
| 7 | __RAM_NO_CACHEABLE_START |
来自链接器 | 正常，无缓存 | 是 | RW/RW | 非缓存 RAM 区域 |
| 8 | __RAM_SHAREABLE_START |
来自链接器 | 正常，无缓存 | 是 | RW/RW | 可共享内存 |
| 9 | 0x40000000 |
6MB | 强烈订购，无缓存 | 是 | RW/RW | AIPS0-2 外围空间（禁用第 6/7 分区） |
| 10 | 0x40600000 |
S32K314 已禁用 | — | — | — | AIPS3；仅在 S32K39x 上有效 |
| 11 | 0x67000000 |
128 MB | 强烈建议 | 是 | RW/RW | QSPI RX |
| 12 | 0x68000000 |
128 MB | 正常，WB/WA | 无 | RW/RW | QSPI AHB 映射区域 |
| 13 | 0xE0000000 |
默认 ARM PPB 大小 | 强烈建议 | 是 | RW/RW | 私人外围总线（SCB、NVIC 等） |
| 14 | __ROM_CODE_START + 0x400000 |
S32K314 为 0 | — | — | — | 附加程序闪光灯（仅对其他衍生产品有效） |
| 15 | 0x44000000 |
S32K314 为 0 | — | — | — | ACE 区域仅在 S32K388 上活跃 |
这是 K344 的 SAF 演示示例中的 MPU 配置：
简单比较这两个 MPU 配置 + 链接器文件可以看出：
-这些内存部分的位置不正确：* (.s32_saf_const_flash_1) * (.s32_saf_const_flash_2)
* (.s32_saf_const_flash_3) * (.s32_saf_const_flash_4)
* (.s32_saf_const_const_flash_4) * (.s32_saf_const_const_flash_4)
* (.s32_saf_const_const_flash_4)
* (.s32_flash_5)-看不到不可缓存的 SRAM 的可执行属性，但这不是 sCheck 所要求的，这可能是 SAF 示例 MPU 设置中的冗余属性——考虑到客户正在运行操作系统，我预计操作系统及其需要一些特定的 MPU 设置和内存部分
应用程序（只是猜测，并不是说这可能是某些问题的根本原因）
无论如何，客户应遵循 SAF 用户手册和 RTD 手册第 " 章内存分配 " 进行正确的 MPU 和链接器文件设置，重复使用恩智浦示例中的短截线不是一个好做法。
特别是当操作系统在 sCheck 测试期间运行时，还需要按照 sCheck 章节" Exclusive Areas（在 BSW Scheduler" 中定义的专属区）进行测试。eMcem 和 RTD 驱动程序中也有类似的排他性区域。
亲切的问候，
Radoslav