Hi (again),
Even though the actual abort handler is not in the scope of SafeTI (according to safety manual) SafeTI shall still provide a method for the application to ask that "was this abort caused by it".
Current solution is not acceptable where application is forced to hack an entry to SafeTI private section and "guess" what kind of errors are trickered. Yes, demo code provides an example how to check errors but it is complete mess, #if 0 type of coding, similar pattern repeated one after one when 1 simple function call could have been done to make code more readable (axidecoder checks), also comment describes different expected value for data fault address than which is actually used and so on.
So basically this kind of interface should exists and be provided by SafeTI where the mask abort checking code from demo app's exception handler should exists
boolean bMaskDataAbort( void )
In case that is impossible (for some function call related issue, though haven't encountered one) then safety manual or some other official place should provide "approved code" which user should copy & paste to it's own exception handler to mask failures caused by SafeTI actual tests.
There is also a need to ask "is this fault injection test running", interface for that should be also provided where proper checks are made to ensure that call really comes due to fault injection:
boolean bFaultInjectionActive( SL_SelfTestType eTest )
Demo application example code does not provide an example for fault injection but proper "as much limiting check as possible" would require usage of sl_priv.c (test activity check), for that reason this code should be also provided and be under SafeTI, currently I have had to make that manually using sl_priv method and dig out what SafeTI does in order to be able to also check that FDIAGCTRL is in proper value. In case FDIAGCTRL is not in proper setting then this is real actual fault which just occured between test activity flag set and actual fault injection
if( (SL_FLAG_GET((int32)FLASH_ADDRESS_PARITY_FAULT_INJECT)) && ((sl_flashWREG->FDIAGCTRL & 0x7U) == 7U) )
{
... do some own application specific fault injection magic (for example call esm callback handler and check that it has noticed this fault injection)
}
I doubt that this is as it is even "as proper" as it could be, most likely also "F021F_FDCTRL_DMODE_TEST_MODE"-bit should be checked from that register and most likely also FPAROVR register content, still it is better in current form that what was used in Demo app there was every possible test mode accepted (!= 0)... As SafeTI has the best understanding&knowing of the register settings how/when the fault is generated it shouldn't be the integrator's job to seek what SafeTI actually do in order to be able to catch/filter the proper situation...
Basically the content of the fault injection query should be something like this, to be effective there should be a separate function per fault injection test to avoid first level "if this brach, else if some other tests" seeking)...
boolean bFaultInjectionActive( SL_SelfTestType eTest )
{
boolean bReturn = FALSE;
if( eTest == FLASH_ADDRESS_PARITY_FAULT_INJECT )
{
if( SL_FLAG_GET(eTest= == TRUE )
{
if( some register are exactly in this and that value where SafeTI has put them )
{
bReturn = TRUE;
}
}
return bReturn;
}
Here is example of misleading commenting (which was referenced above) in Demo application 0xFFF81000 vs actually used 0xFFFF0900 and now I should put this kind of code to my application (I have tested this test and that 0xFFFF0900 is correct one so this is just commenting error but still)...
/*
* DAbort due to access to illegal transcation to Peripheral Seg1 Interconnect
* 0x00000008 indicates that it is an external abort caused by read and is AXI decode error
* 0xFFF81000 is the reserved location accessed to create the Peripheral Seg1 interconnect error trap AXI decode error
*/
if ((TRUE == SL_FLAG_GET(PERIPHSEGINTRCNT_RESERVED_ACCESS)) &&
((0x00000008u == (0x00000008u & _SL_Get_DataFault_Status())) &&
(0xFFFF0900 == _SL_Get_DataFault_Address()))) {
maskDAbort = TRUE;
}
And just by a bit or work this could be written into much more readable form reducing 2 code lines per if and making impossible to make some kind of type != vs == mistake into one of the multiple similar checks
if( bDataAbortAxiDecoder( (int32)PERIPHSEGINTRCNT_RESERVED_ACCESS, 0x00000008u, 0xFFFF0900U ) ) // NOTE: different value than in comment
{
maskDAbort = TRUE;
}