您好(再次)、
即使实际的中止处理程序不在 SafeTI 的范围内(根据安全手册)、SafeTI 仍应提供一种方法让应用程序询问"此中止是否由它引起"。
如果应用程序被迫破解 SafeTI 私有部分的入口并"猜测"哪些类型的错误会被破解、则当前的解决方案是不可接受的。 是的、演示代码提供了一个如何检查错误的示例、但它是完全混乱的、#if 0类型的编码、类似的模式在一个之后重复一个、此时可以执行1个简单的函数调用来使代码更可读(轴编码器检查)、 此外、注释描述了数据故障地址的预期值与实际使用的值不同、依此类推。
因此、基本上这种接口应该存在并由 SafeTI 提供、其中应该存在来自演示应用的异常处理程序的屏蔽中止检查代码
布尔型 bMaskDataAbort( void )
如果不可能(对于某些与函数调用相关的问题、尽管尚未遇到)、则安全手册或其他官方机构应提供"已批准的代码"、用户应将其复制并粘贴到其自身的异常处理程序、以屏蔽由 SafeTI 实际测试导致的故障。
还需要询问"此故障注入测试是否正在运行"、还应提供相应的接口、以便进行适当的检查以确保呼叫真正因故障注入而产生：
布尔型 bFaultInjectionActive (sl_SelfTestType eTest)
演示应用示例代码不提供故障注入示例、但正确的"尽可能多的限制检查"需要使用 sl_priv.c (测试活动检查)、因此也应提供此代码并将其置于 SafeTI 之下、 目前、我必须使用 sl_prive 方法手动创建、并挖掘 SafeTI 的功能、以便还能检查 FDIAGCTRL 是否具有正确的值。 如果 FDIAGCTRL 设置不正确、则这是实际故障、该故障是在测试活动 标志设置和实际故障注入之间发生的
if (((sl_FLAG_GET ((Int32) FLASH_ADDRESS_奇 偶校验_FAULT_INject)))&(((sl_flashWREG->FDIAGCTRL & 0x7U)== 7U)))
｛
(笑声) 执行一些自己的应用特定故障注入魔术(例如调用 ESM 回调处理程序并检查它是否注意到了此故障注入)
｝
我怀疑这是因为它甚至是"正确的"、很可能也应该从该寄存器检查"F021F_FDCTRL_DMODE_TEST_MODE"位、而且很可能还应该检查 FPAROVR 寄存器内容、 在当前的形式中、演示应用中使用的测试模式仍然是可以接受的(！= 0)... 由于 SafeTI 对寄存器设置的了解程度和了解程度都很高、因此集成商不应寻求 SafeTI 实际执行的操作、以便能够捕获/过滤正确的情况...
基本上、故障注入查询的内容应该是这样的、为了有效、每个故障注入测试应该有一个单独的函数、以避免第一级"如果这种情况发生、否则会进行其他测试"。
布尔型 bFaultInjectionActive (sl_SelfTestType eTest)
｛
布尔 bReturn = false；
if (eTest == FLASH_ADDRESS_奇 偶校验_FAULT_INject)
｛
if (sl_FLAG_GET (eTest== true)
｛
if (某些寄存器正好位于 SafeTI 将它们放置在该值中)
｛
bReturn = true；
｝
｝
返回 bReturn；
｝
下面是演示应用程序0xFFF81000与实际使用的0xFFFFFF0900之间的误导性注释示例、现在我应该将这种代码放入我的应用程序(我已经测试此测试、0xFFFF0900是正确的、所以这只是注释错误、但仍然如此)。。。。
/*
*由于访问外设段1互连而导致的 DAbort
* 0x00000008表示它是由读取引起的外部中止、是 AXI 解码错误
* 0xFFF81000是被访问用来创建外设段1互连错误陷阱 AXI 解码错误的保留位置
*
if ((TRUE =sl_FLAG_GET (PERIPHSEGINTRCNT_RESERVE_ACCESS)))&&
((0x00000008u =(0x00000008u &_SL_GET_DataFault_Status ()))&&
(0xFFFF0900 =_SL_GET_DataFault_Address ()))｛
maskDAbort = true；
｝
只需一个位或一个工作、就可以将其写入更易读的格式、从而减少每个 IF 的2个代码行、并且无法进行某种类型的！= vs =错误地进行多个类似检查之一
if (bDataAbortAxiDecoder ((Int32) PERIPHSEGINTRCNT_RESERTED_ACCESS，0x00000008u，0xFFFFFF0900U)//注意：值与注释中的值不同
｛
maskDAbort = true；
｝