X-CUBE-CLASSB-L4 (STL) — Fault Injection Method for Flash/CPU/RAM Self-Tests on STM32L451CET

[Kim GS]

Subject: X-CUBE-CLASSB-L4 (STL) — Fault Injection Method for Flash/CPU/RAM Self-Tests on STM32L451CET

I am applying X-CUBE-CLASSB-L4 (Self-Test Library, STL) on an STM32L451CET MCU to implement CPU/Flash/RAM self-tests for IEC 60730-1 Class B certification.

Main issue: No matter what method I try, the Flash test never passes (always reports a failure / never completes successfully under normal conditions).

Certification requirement: Our certification body requires us to demonstrate both the normal (pass) case and the fault (failure) case for each test, specifically by actually altering real values during test execution:

• CPU test: by actually changing register values during the test
• Flash test: by changing the CRC value, or modifying Flash memory contents while the test is running
• RAM test: by modifying RAM contents while the test is running

I understand that ST's recommended method is to use STL_ArtifFailingConfig to perform fault injection. However, this only simulates a failing configuration internally within the library, and I'm not sure it satisfies the certification body's requirement of injecting faults via actual, real-time memory/register modification.

My specific questions:

1. Since the X-CUBE-CLASSB-L4 library files are provided as a precompiled binary (.a/.lib), is there a way to verify that the self-test logic is actually executing correctly when the binary is integrated as-is, beyond just checking the return status? Is there any internal trace, debug hook, or instrumentation available for this verification?
2. What is the correct configuration/usage to make the Flash test pass successfully under normal conditions? A working example or reference project would be very helpful, as our current integration never reports a pass.
3. Is there a supported method to perform fault injection via actual modification of real values (e.g., directly altering a CRC value in Flash, corrupting a RAM cell, or changing a CPU register value at runtime) rather than relying solely on STL_ArtifFailingConfig? If STL_ArtifFailingConfig is the only supported method, is there documentation explaining why this is considered equivalent to real fault injection from a certification standpoint?
4. If real-value fault injection is not directly supported by the library, is there any additional documentation, application note, or reference library that addresses this gap — something we could present to our certification body as justification that STL_ArtifFailingConfig-based fault injection is functionally equivalent to real fault injection?

Any example code, test reports, or certification-support documentation you can share would be greatly appreciated.

Thank you in advance for your support.