STM32 Safety Platform

Benefits of the combines package

The safety manual provided by STMicroelectronics list the safety requirement (hardware, software and application level) considered in the safety analysis of the microcontroller. The following list gives an (incomplete) overview which safety requirement is covered by using the Flexible Safety RTOS and the Safety Addon:

CPU_SM_1 - Control flow monitoring in application software is covered by Safety Addon (PFM)
CPU_SM_4 - Stack hardening for application software is covered by Safety Addon (E2E)
MPU_SM_0 - Periodical read-back of MPU configuration registers is covered by Flexible Safety RTOS
FLASH_SM_0 - Periodical software test for Flash memory is covered by STL or Safety Addon (CRC)
FLASH_SM_1 - Control flow monitoring in application software is covered by Safety Addon (PFM)
RAM_SM_0 - Periodical software test for SRAM memory is covered by STL
RAM_SM_2 - Stack hardening for application software is covered by Safety Addon (E2E)
RAM_SM_3 - Information redundancy for safetyrelated variables in application software is covered by Safety Addon (E2E)
RAM_SM_4 - Control flow monitoring in application software is covered by Safety Addon (PFM)
RAM_SM_5 - Periodical integrity test for application software in RAM is covered by Safety Addon (CRC)
BUS_SM_1 - Information redundancy in intra-chip data exchanges is covered by Safety Addon (E2E)
DMA_SM_1 - Information redundancy on data packet transferred via DMA is covered by Safety Addon (E2E)

Note: your used peripheral interfaces (CAN, I2C, SPI, USB, ETH, ..) may require information redundancy techniques.

Integration Steps

To demonstrate the features and integration of the X-CUBE-STL in a system using the Flexible Safety RTOS, you just need to download the following packages provided by Embedded Office:

The Flexible Safety RTOS demo package
The Safety AddOns

and the single package provided by STMicroelectronics:

The X-CUBE-STL package

As preparation for the integration, please extract all packages from Embedded Office into a single folder of your choice. Afterwards, add the X-CUBE-STL package to get the resulting file structure:

+- addons <- safety addOns
+- bsp <- Board support package
+- cert-mpu <- flexible safety RTOS
+- demo
| +- addons
| | +- 03_stlib <- root of the demo project
| | | +- source
| | | | +- app.c/.h <- startup of the application
| | | | +- app_crc_perf.c/.h <- demonstrate the safety addon
| | | | +- stl_app.c/.h <- demonstrate the X-CUBE-STL
| | | | +- app_hooks.c/.h <- contains Idle task hook for online
| | | | tests
| | | +- STM32_Safety_STL <- X-CUBE-STL package

Now you can start with the guided integration steps. The steps are:

add the X-CUBE-STL to the make process
add required sections of the X-CUBE-STL to the link process
program the checksums for the flash tests
integrate and execute the X-CUBE-STL in code

The steps are explained in detail in the following chapters which is an example for IAR compiler.

Makefile

Embedded Office provides an example makefile for demo projects. This makefile is located in the demo root folder. This makefile organizes the BSP, RTOS and Safety AddOns build. Now we need to integrate the X-CUBE_STL into the build process.

Add STM32_Safety_STL path for sources and includes:

STL_PATH = ./STM32_Safety_STL
...
VPATH += $(STL_PATH)/Inc
VPATH += $(STL_PATH)/Src

Add STL_Lib.a to get it linked:

LIB_FILES = $(STL_PATH)/Lib/STL_Lib.a

Add compiler define STM32F407xx for use with stl_user_param_templates.c, i.e. selection of the correct hardware. The file stl_user_param_templates.c lists the possible hardware variants and therefore the possible defines.

CC_OPTS += -DSTM32F407xx

Linker Command File

Similar to the makefile, Embedded Office provides a linker command file in the demo root folder. The linker command filename depends on the development environment. For IAR the file extension is '.icf'.

In this file, we add a "backup_buffer_section" for the X-CUBE_STL RAM tests:

define block FIXED_ORDER_RAM with fixed order {
  section backup_buffer_section, readwrite
};
place in core_ram_1 {
  block FIXED_ORDER_RAM
};

Note: This section is used during RAM tests, so that RAM content is not destroyed.

FLASH Test Checksums

Ensure that CRC checksums for flash tests are also flashed when downloading the demo application. The document "STM32F4 Series self-test library user guide" gives a good explanation where the checksums must be stored in flash. It also provides information and a link to the STM32CubeProgrammer, which can be used as a CRC programming tool.

When using the Lauterbach Trace32 debugger, following code in a scriptfile *.cmm will calculate the CRC checksums and place them to the required locations:

;Set checksums for flash test, must match flash test settings:
; 4 sections with 1kB each, starting from 0x08000000
Data.SUM 0x08000000--0x080003ff /byte /CRC32
Data.Set 0x080FF000 %Long Data.SUM()
Data.SUM 0x08000400--0x080007ff /byte /CRC32
Data.Set 0x080FF004 %Long Data.SUM()
Data.SUM 0x08000800--0x08000bff /byte /CRC32
Data.Set 0x080FF008 %Long Data.SUM()
Data.SUM 0x08000C00--0x08000fff /byte /CRC32
Data.Set 0x080FF00C %Long Data.SUM()

Demo Application

Now we can call the X-CUBE-STL test function within the application. Please consider the following when choosing the calling location:

all test functions require privileged access permissions
the test functions are locking the interrupts for a limited amount of time (see the STM32F4 Series self-test library user guide for details)

For this demonstration, we choose the hook function, which is called within the idle time of the Flexible Safety RTOS: Example:

#include "stl_app.h"

void App_TaskIdleHook(void)
{
  /* The STL must be executed with privileged level, 
   * in order to be able to modify certain core registers
   * (for example the PRIMASK register).
   */
   /* Note: Idle task hook runs in privileged mode */
  StlSingleTest();
  StlArtificialTests();
  StlMultipleTests();
  StlRamTestOneSubset();
  StlRamTestMulSubsets();

  /* Flexible Safety RTOS Monitoring */
  err = SPMonMpuCfgChk(); 
  if (err != SP_MON_ERR_NONE) {
   /* Fatal Error: stop CPU in safety state */
    OS_SAFETY_CRITICAL_EXCEPTION(); 
  } 
}

Note 1: The idle task stack must be big enough. See the STM32F4 Series self-test library user guide for the required STL stack usage.

Note 2: The example above just combines all STL demos. In a real project the integrator has to select the fitting tests covering the safety requirements.

Note 3: The Safety Manual of the Flexible Safety RTOS forces the execution of online tests of the MPU configuration.

As an alternative, one or more STL tests can be performed as POST tests before starting the safety application:

#include "stl_app.h"

int main (void)
{
  ...
  /* POST test shall be executed before OSInit() in privileged mode */
  StlSingleTest();
  StlArtificialTests();
  StlMultipleTests();
  StlRamTestOneSubset();
  StlRamTestMulSubsets();

  /* initialize realtime kernel */
  OSInit();
  ...
}

Conclusion

In conclusion, the integration of the STM32 Self-Test Library with our Flexible Safety RTOS and Safety AddOns offers a powerful solution for software developers working on safety-critical projects. By leveraging the comprehensive safety checks, real-time fault detection, and diagnostic reporting capabilities of the self-test library, developers can ensure exceptional functional safety, reliability, and compliance with industry regulations.

With our integration service, the process becomes seamless, saving time, and reducing costs. Take your safety-critical projects to the next level and unlock the full potential of your software development with our integrated solution. Contact us today and let us assist you in building high-quality safety products efficiently and effectively.