RM46L430: Clarification of the SL_SelfTest_SRAM Description in SafeTIDiagnosticLibrary-User'sGuide-v2.3.1

Hi Mark,

Sorry for the delay in providing an answer. This one dropped through the cracks unfortunately. I will forward your question to our SW team so they can address it.

Hi Mark,

It seems our SW lead hasn't been able to get to this post so I had a closer look.

First, yes, I think there is a misalignment between the documentation and the actual software in regard to the return value as described in the user guide and what is implemented in the code. I will open a bug ticket in our CQ system on this so it can be corrected (most likely only a documentation fix since this is the least effort/impact).

Second, fault injection is intended to check the error reporting path and whatever fault handler you have in place. This will take some code at the system level to validate that the test actually worked as planned/intended. i.e., when the fault is injected, it should result in some action within the system level SW. This could include an interrupt and nERROR assertion or for non-critical bugs, simply an ESM flag set which is checked periodically at the system level, or even a CPU exception (abort) which would need to be serviced at the system level. Since it involves this level of interaction, there is no way to set a pass/fail within the context of the safeTI library; and, therefore, the pointer to the enum will not reflect the true status of the test in the case of a fault injection.

Hi Chuck,

Correct me if I'm wrong, but based on my inspection of sl_esm.c (SafeTI Diagnostics Library code), the ESM handlers mask the call to the ESM callback if a test is in progress. Even if I assume that the Safety Manual was updated to included detailed information concerning the test sequence, any addresses used for injection tests and the expected impact on the state of the CPU and peripherals, then how can I verify any of this when the ESM handler does not even call the registered 'ESM_AppCallback' when a test is active?

Right now I've implemented a wrapper exception handler around the SafeTI Diagnostics Library FIQ / IRQ (sl_esm_high_intr_handler & sl_esm_low_intr_handler) and my own test active flags (the SafeTI diagnostics Library one is private!). Without this I can't even run the fault injection tests that result in a FIQ as it's not possible to disable FIQ once it's been turned on and the ESM handler does not cancel any fault injection. In this case, the SafeTI Diagnostics Library implementation just gets stuck in loop; execute fault injection instruction, raise FIQ, ESM handler does not clear fault injection, ESM handler callback is masked, interrupt returns and CPU reruns the fault injection instruction! Stuck in loop!

Will your bug ticket fix the description of all tests? Without a huge updated there will not be enough information to implement the missing system part of the Self Test. Right now it's not even mentioned that this is not included. The API for the Self Tests and Safety Manual just imply that if I 'run the test' I cover the described safety measure in my safety concept. This controller is targeted for safety environments, and my product needs to be functionally safe which means that I can't just add code from reverse engineering the SafeTI Diagnostics Library. This will not be accepted by a certification authority.

It there more information available?

Am I missing documents?

Is this all just missing from the Safety Manual?

When can I expect the updated documents?

Regards,

Mark.