[参考译文] TMS570LC4357：在 TMS570系列 MCU 上通过 MPU 防止微处理器读取/写入

嗨 phitastic,

从 HALCoGen 为任何新工程生成的默认配置将始终阻止空指针写入。

您可以看到、在特权和用户模式下、闪存的前4MB 都配置为只读、但我们只保留前4MB 的执行。 因此、相同的配置也适用于矢量、因为它们也是从0x0到0x20的。 因此、这里不会进行空指针写入。

这可能是您的情况下的问题、也许我们不应该为矢量保留 No execution (noexec)、这是因为 resetEntry (0x0)的闪存的起始地址将只指向代码起始地址、在本例中 _c_int00。

因此、向量应该执行0x0以将执行移动到代码中。 因此、我们可能不会使向量保持无执行状态。

——
谢谢、此致、
Jagadish。

谢谢、 jagadish gundavarapu --添加 EXEC 标志可以解决问题！  现在、我们同时具有  nullptr 写保护和读保护、类似于前面链接的文章(使用 ARM Cortex-M MPU 进行 NULL 指针保护)中的方法。

我看到的一个问题是启用了 SafeTI 测试。  这些函数看起来像是执行矢量表的读取(因此会导致 MPU 故障)：

56. b svcEntry
 00000000：??? 目标无法读取0x00000000 [代码= 0x1]
 57 prefetchEntry
 00000004：??? 目标无法读取0x00000004 [代码= 0x1]
 58 b prefetchEntry
 00000008：？？？ 目标无法读取0x00000008 [代码= 0x1]
 59 DataEntry
 0000000c：??? 目标无法读取0x0000000C [代码= 0x1]
 60 b DataEntry
 00000010：??? 目标无法读取0x00000010 [CODE=0x1]
 61 b phantomInterrupt
 00000014：??? 目标无法读取0x00000014 [CODE=0x1]
 62 LDR PC、[PC、#-0x1b0]
 00000018：？？？ 目标无法读取0x00000018 [CODE=0x1]
 63 LDR PC、[PC、#-0x1b0] 0000001c
：？？？ 目标无法读取0x0000001C [代码=0x1] 

我移动 flashBadECC1并flashBadECC2离开了0x00区域、但仍然看到上面的问题。  您也许知道哪个自检可能执行这些读取、从而与0x00 - 0x20处的 MPU 读取保护相冲突？  

谢谢！

嗨 phitastic,

我 flashBadECC1flashBadECC2从0x00区域移动并离开、但仍然看到上面的问题。  您也许知道哪个自检可能执行这些读取、从而与0x00 - 0x20处的 MPU 读取保护相冲突？  [报价]

您是正确的 flashBadECC1和 flashBadECC2将使用此矢量表位置。 但我不记得其他哪些测试可以使用该区域。

我也怀疑 IRQ 和 FIQ 中断也依赖于此区域：

我想、禁用此向量位置的读取权限可能不是一个好主意。 无缝执行任何应用程序可能至少需要读取权限。

——
谢谢、此致、
Jagadish。

谢谢、 jagadish gundavarapu。  有趣的是-在原来的文章中它指出在正常的异常处理中、MCU 使用的指令与 LDR/STR 不同 、并且"看起来 MPU 不会检查除 LDR/STR 以外的指令对该区域的访问、例如在 Cortex-M 异常进入期间读取向量地址。"   因此、如果 Cortex-R 的行为相似、则可以在向量位置禁用读取访问。  在我的测试中、这对于非 SafeTI 构建确实可以正常工作(不过、我还没有详尽地进行测试)。

嗨、Phitastic,

您能否进一步说明一下。 我不明白。

——
谢谢、此致、
Jagadish。

根据我所链接的文章、使用`PRIV_NA_USER_NA`锁定矢量表应该可以很好地工作、因为 MPU 仅防止 该区域中的 LDR/STR、但中断操作使用不同的指令。 非 SafeTI 版本确实是如此。  当我将 SafeTI 库与其一系列启动测试结合使用时、其中一些测试会导致中止、而这很难确定。 我假设一些测试(ECC？)会产生一些副作用、 这实际上会导致从该0x00 - 0x20区域读取。   

谢谢 jagadish gundavarapu。  鉴于难以在 SafeTI 库中确定矢量依赖性、我将把该问题标记为"暂时关闭"。