Skip to main content
Kim GS
Visitor II
June 30, 2026
Solved

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

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.

Nabil'osBest answer
ST Employee
October 9, 2026

Hello Kim,

here are some clarifications on your questions:

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.

    • STL_ArtifFailingConfig is not really a fault injection method. Is more  a method to make the STL returning a FAIL message without modifying and that way to allow the correct testing of main application software. So you should see STL_ArtifFailingConfig as a way/tool to test your application software and not the STL.
  2. 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?
    • No, the lib is certified and we provide certification lab all evidences
  3. 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.
    • Correct usage to make the Flash test pass is as it is described in the library documentation and in the ClassB example. If you are still feels lost, you can follow the instructions for integrating the library into a fresh project in AN6179 (ignoring the Motor-control parts). Maybe you can face the flash section alignment problems. Main symptom of those is when the Flash test is failing when flashed and run by the debugger in CubeIDE, but not failing when the same binary is flashed by CubeProgrammer. This is due to there being holes between the unaligned sections which are 0xFF in one and 0x00 in the other. You can also verify the contents of the MCU flash as programmed by CubeIDE against the same binary using CubeProgrammer.
  4. 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?
    • None of these methods of fault injection are in any capacity officially supported and should not be necessary for certification. Nevertheless, it is possible (but we do nor recommend that as overcomplicated and for us not of added value besides the certification) to: 
      • Flash is trivial, just rewrite a single word in flash using CubeProgrammer – best practice for this is always changing the value of some unused ISR vector in the vector table in the beginning of the Flash - it is a harmless change that doesn't affect the program and the location is easy to find.
      • For RAM, you can run the test on unused memory, place a watchpoint breakpoint on read from that memory location, and step through the disassembly to overwrite the read value in the CPU register to something else. Another method is to compile the project with IRQ masking disabled and test a memory location that you are periodically writing to within IRQ. Sooner or later, this will modify the location during the test and fail it.
  5. 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?
    • That's what the certification of the library is for, so that you and the certification authority can trust it on this.

 

Best regards,

Nabil

View in thread

1 reply

Nabil'osBest answer
ST Employee
October 9, 2026

Hello Kim,

here are some clarifications on your questions:

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.

    • STL_ArtifFailingConfig is not really a fault injection method. Is more  a method to make the STL returning a FAIL message without modifying and that way to allow the correct testing of main application software. So you should see STL_ArtifFailingConfig as a way/tool to test your application software and not the STL.
  2. 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?
    • No, the lib is certified and we provide certification lab all evidences
  3. 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.
    • Correct usage to make the Flash test pass is as it is described in the library documentation and in the ClassB example. If you are still feels lost, you can follow the instructions for integrating the library into a fresh project in AN6179 (ignoring the Motor-control parts). Maybe you can face the flash section alignment problems. Main symptom of those is when the Flash test is failing when flashed and run by the debugger in CubeIDE, but not failing when the same binary is flashed by CubeProgrammer. This is due to there being holes between the unaligned sections which are 0xFF in one and 0x00 in the other. You can also verify the contents of the MCU flash as programmed by CubeIDE against the same binary using CubeProgrammer.
  4. 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?
    • None of these methods of fault injection are in any capacity officially supported and should not be necessary for certification. Nevertheless, it is possible (but we do nor recommend that as overcomplicated and for us not of added value besides the certification) to: 
      • Flash is trivial, just rewrite a single word in flash using CubeProgrammer – best practice for this is always changing the value of some unused ISR vector in the vector table in the beginning of the Flash - it is a harmless change that doesn't affect the program and the location is easy to find.
      • For RAM, you can run the test on unused memory, place a watchpoint breakpoint on read from that memory location, and step through the disassembly to overwrite the read value in the CPU register to something else. Another method is to compile the project with IRQ masking disabled and test a memory location that you are periodically writing to within IRQ. Sooner or later, this will modify the location during the test and fail it.
  5. 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?
    • That's what the certification of the library is for, so that you and the certification authority can trust it on this.

 

Best regards,

Nabil

    Terms & ConditionsAccessibility statement