我希望对我们为我们的应用选择的 ESM 配置运行一些最终测试。 这些测试旨在注入故障、然后通过我们的 ESM 处理程序指示哪个诊断使我们跳闸。 我在 Halcogen 中配置了以下诊断、根据它们在我们的应用中的使用情况或作为管理安全标准的要求选择每个诊断。
1：MIBADC2
6：闪存 ECC 单一
7：NHET 奇偶校验
11：内部时钟监控器
15：VIM 奇偶校验
18：MIBSPI3奇偶校验
19：MIBADC1奇偶校验
26：RAM ECC 偶数
27：CPU 自检
28：RAM ECC ODD
31：CCM 自检
35：EEPROM 单通道
36：EEPROM double
37：IOMM Mux 配置
所有 ESM 故障被配置为切换 nERROR 并触发一个低电平中断。
我们的应用和电路板 IO 架构专为使用 nERROR 引脚的所有安全输出而设计、因此在发生 ESM 错误时、我们会切断所有安全输出的电源。
我对 ESM 配置的验证是利用测试构建中的自检例程在启动检查完成后调用 ESM 故障、期望运行 ESM 处理程序、我们将看到故障得到处理。 指示我们已识别的故障可由应用捕获并适当处理。
中断处理程序如下所示
#pragma weak (esmGroup1Notification)
void esmGroup1Notification (uint32 channel)
｛
//在用户代码开始和用户代码结束之间输入用户代码。 */
*用户代码开始(1)*/
/*保存 ESM 通道 c：000.SYS.A.115.v7 */
uni_cfg_set_ESM (0U、channel)；
//
*用户代码结束*/｝
//*用户代码开始(2)*/
*用户代码结束*/
#pragma weak (esmGroup2Notification)
void esmGroup2Notification (uint32 channel)
{//
在用户代码开始和用户代码结束之间输入用户代码。 */
*用户代码开始(3)*/
/*保存 ESM 通道 c：000.SYS.A.115.v7 */
Uni_cfg_Set_ESM (1U、通道)；
/*用户代码结束*/
｝ uni_cfg_set_ESM 例程会将"通道"保存为 FEE。 随后的加电将允许在复位前询问此值、以便我们有机会确定我们看到的 ESM 故障类型。 我已针对以下渠道成功测试了这一点：
1、7、11、15、18、19、26、10、6、35
在我认为此验证练习已完成之前、我有以下问题、希望 TI 提供您的意见：
1.请确认当时钟监控器诊断失败时 MCU 将恢复到的时钟-是 LPO 吗？
2.确认 checkRAMUERRTest()和 checkFlashEEPROMECC()都将触发 ESM 通道6故障
3.是否有方法注入 RAM ECC 奇校验故障(通道27)？
4.是否有方法注入 EEPROM 双位故障(通道36)？
5.当我从应用程序循环中运行 cpuSelfTest()时，处理器实际上会挂起，并且我已经阅读了许多文章，表明这是预期的。 是否正确地说、在发生真正的运行时 CPU 错误时、我不能指望我的应用程序有机会执行、因此无法尝试记录通道源 ID 以收费？
6.与5类似，CCM 自检例程将不允许我的应用程序捕获并记录信道源 ID 以收费？
7.在每个 ESM 错误的情况下、nERROR 将被驱动为低电平、并在 EKR 寄存器被清除前保持低电平。 我在信道1、7、11、15、18、19、26、10、6、35中成功捕获了这种行为、但对于我上面询问的其他信道、我无法显示 nERROR 保持低电平。
我很感谢这些测试在启动代码中的启动时运行、但为了进行我自己的验证、我希望每个测试至少在工作台上一次触发适当的 nERROR 响应、并记录为 FEE。 如果有一种更好的方法来记录未来的调试、那么触发故障的 ESM 错误也是我感兴趣的。
谢谢
Jamie
7.在每个 ESM 错误的情况下、nERROR 将被驱动为低电平、并在 EKR 寄存器被清除前保持低电平。 我在信道1、7、11、15、18、19、26、10、6、35中成功捕获了这种行为、但对于我上面询问的其他信道、我无法显示 nERROR 保持低电平。
QJW> ESM 组2和 ESM 组3的通道中的任何错误都会将 ERROR 引脚拉低。 组1错误具有可配置的错误引脚行为。
BTW、#5和#6中的费用是多少？
在下面的屏幕截图中、您可以看到所需组1通道的典型 halcogen 配置：
以 MIBADC2为例、您可以在下面的屏幕截图中看到我在运行应用程序循环之前调用的带有 adc2ParityCheck 的编译时看到的活动。 正如预期的那样、我的调试输出显示了注册为故障的正确 ESM 通道、并且 nERROR 引脚在检测到故障时保持低电平。
现在、如果我运行一个相似的构建、但是这次调用 CheckFlashECC、正确的通道被记录为生成 ESM 错误、但是由于某种原因、nERROR 引脚不保持低电平。 我的应用中的所有逻辑与我调用 checkFlashECC 来代替 adc2ParityCheck 的逻辑是一样的。 那么、为什么 nERROR 变为高电平？ 我必须理解这一点、因为生产意图构建都是假设我配置的任何 ESM 错误都会导致 nERROR 被驱动并保持低电平、直到应用程序确定可以通过清除 EKR 寄存器来释放它。
大家好、我能告诉我为什么 nERROR 在我运行这些自检例程时不保持低电平。 下面是运行 checkRAMEcc()函数的示例。 我的 ESM 处理程序正确捕获了通道26故障、但 nERROR 不保持低电平：
我确实需要查看验证数据、至少一次、我希望启用的每个诊断程序都在运行。 相应的 nERROR 活动。 Halcogen 始终采用相同的配置方式、我无法理解为什么有些人会允许 nERROR 返回到高电平状态。 感谢您对此提供的一些意见、因此我可以结束验证。
当应用程序跳转到 undefEntry 时、似乎正在执行未定义的指令。 现在、从对主题的阅读中可以看出、这是由于请求了 ARM 与 Thumb 指令(请参阅 SPNA218 sec 2.2)。 SPSR_UND 寄存器的下面屏幕截图、返回根本原因的最佳步骤是什么？ 从我可以看到、MCU 处于 ARM 模式、也设置为用户模式。 这是否表示中断已将我们从系统模式切换回用户模式？ 如何最好避免这种情况-在运行 FEE 例程之前禁用中断？
