Question about the self-test of the internal flash memory

[Heinz_Baumer]

Does anyone know what settings are needed to check the internal flash memory using the STL library?

I wrote a small test firmware (for a 61508 safety application without TZ) using the STL library, which is supposed to perform a self-test flash memory check.

However, this test always fails.

I ran the checksum check using STM32CubeProgrammer v2.20.0.

I had to manually enter the settings for FlashStart, FlashEnd, and FlashSectionSize (0x08000000 0x0800E000 0x00010000) because the macros from the readme file didn't work.

The STM32CubeProgrammer then reports: CRCs area injected successfully.

After loading the modified ELF file, the STM32CubeProgrammer displays:

Number of segments: 2
segment[0]: address= 0x8000000, Size = 0xC314
segment[1]: address= 0x800E000, Size = 0x2000

But what settings should be specified to perform the flash test?
Unfortunately, this information is not available in the manual or the STL documentation. 

I've already tried the following unsuccessfully:
1st attempt: #define FLASH_SECTION_SIZE 0xE000U
2nd attempt: #define FLASH_SECTION_SIZE 0xC400U
3rd attempt: #define FLASH_SECTION_SIZE 0x10000U
each with: #define TEST_FLASH_SECTION_NB 1


The StlErrorHandler() is always called because the flash check fails. (FlashTmStatus: STL_FAILED)


Does anyone know what settings need to be changed:
  a) when calling the STM32CubeProgrammer and
  b) for testing the flash
so that it works?

[AScha.3]

Many questions - but which cpu you asking about ?  no info given, so what you expect ?

[Heinz_Baumer]

Sorry.

We use the STM32H503CBT.

[AScha.3]

Hm, has "normal" flash;

Flash can only be erased and written, then read for verify , whether its correct; thats always this way.

on download/flash the image is verified (if you sect it in CubeProgrammer);

so what you wanna "check" ?

+

Some series have error detection+correction in flash , if need 100% safety always, example H7 series ->

[Heinz_Baumer]

Hello.

Flash testing is required for safety software that must meet a SIL (Safety Integrity Level) according to DIN EN 61508.

This includes the need for cyclical self-tests of the CPU, RAM, and Flash memory, as well as all inputs and outputs.

These tests must be performed 100 times more frequently than standard safety tests.

The TÜV-certified X-CUBE-STL-H5 software is required and has the following features:

• STL tests of the CPU Arm® core
• STL tests of the Flash memory
• STL tests of the RAM.

These tests specifically ensure that the contents of the Flash memory are still valid ( the test FLASH_SM_0  for example).

For this to work, the firmware image must first be calculated and modified using the CRC tool of the STMCubeProgrammer.

[AScha.3]

Aha,  ok. I never needed this...so i dont know. 

see: https://community.st.com/t5/stm32-mcus-embedded-software/are-there-tutorials-how-to-use-the-safety-libraries/td-p/129255

Did you ask sidekick ?

->

1. Overview: Using the STL Safety Library

The STM32 Self-Test Library (STL) is designed to help you implement safety mechanisms in your application, such as periodic self-tests for RAM, Flash, and CPU. The following sections provide a comprehensive guide to integrating, configuring, and using the STL safety library in your STM32 project.

---

2. Integration Steps

Project Setup

• Create a new application project with a suitable directory structure.
• Use STM32CubeMX to automate the process if possible.

Add STL Library Files

• Copy the Middlewares/ST/STM32_Safety_STL directory from the STL example into your project.
• Add all STL source files from the SRC directory to your project.
• Assign the INC directory as an additional include directory.
• Add the library object file from the LIB directory as an additional library for the linker.

IDE-Specific Configuration

• For STM32CubeIDE, EWARM, and Keil MDK, follow the detailed steps to link source files, set include/library paths, and update linker scripts:
  • In STM32CubeIDE, add the library and include paths, and update the linker file to include the backup_buffer_section for RAM STL tests.
  • In EWARM and Keil MDK, adjust the project and linker settings as described in the documentation.

---

3. Configuration and API Usage

Configure Flash Memory Range

• Update the STL_ROM_END_ADDR in stl_user_param_template.c to match your project's memory range and ensure consistency with the linker script and CRC tool.

Optional Preprocessor Switches

• Enable options like STL_SW_CRC (for software CRC) or STL_ENABLE_IT (to enable interrupts during certain tests) as needed.

Develop STL Flow Control

• Implement the required sequence of STL API calls in your application, repeated periodically as required by your safety task.
• Ensure all user structures for memory tests are properly filled and checked.
• The STL API provides status information via function return values and test result values, which should be checked in your application logic.
• For detailed API usage, refer to the stl_user_api.h file and Section 7.2 User APIs in the documentation.

---

4. Building and Running

• Build the project and launch the compiled binary.
• Check the result (e.g., LED toggling behavior) to verify correct operation.
• Use the ST CRC tool or another suitable CRC tool to generate the necessary structure for flash test execution and automatically add computed CRCs to the binary.

---

5. Summary

To use the STL safety library:

• Integrate the library files and configure your IDE as described.
• Set up memory ranges and optional preprocessor switches.
• Implement STL API calls in your application code, checking results as required.
• Build, run, and verify your application’s safety mechanisms.

For additional support or to discuss your specific application with ST experts, you’re welcome to join conversations in STM32 forums.

Sources:

Collapse

AN6179_Rev1.pdf

[p. 14]

UM3267_Rev1.pdf

[p. 23]

UM3267_Rev1.pdf

[p. 22]

UM3267_Rev1.pdf

[p. 4]

[Ozone]

I don't know ST's STL library, because my company does not use any STM32 devices in safety-critical applications.

Which more or less means we use a "hand-coded" approach here, at least for certain devices.

First, we run the test only over code, not (constant) data that end up in the Flash. For that end, we  had to split the application in sub-segments, were usually "end-of-code" section separates actual code from constant data.
The latter usually depends on the application size, and might either require frequent adaption, or a relatively static Flash layout.

With the start address and the end address of the code section known, the checksum is calculated by an external tool in the post-build process.
It is patched into the SREC file into a known specific location, a "program header structure", which contains the start and end addresses as well, and which is of course outside the code range.
At runtime, the application cyclically calculates the checksum itself, and compares it with the one stored in the header.

In case of issues, check that both the external tool and the application code treat unused/unprogrammed Flash areas the same way.

This method applies to most of our older hardware, often using relatively arcane architectures and toolchains. And there are some legal reasons that keep me from sharing all details.

For new development my company now only considers commercial ECUs, which means the ECUs for SIL-2 applications come with this feature built-in by the vendor.

[Heinz_Baumer]

Hi AScha.3

I've read the entire documentation.
However, I'm having trouble implementing it in the STM32CubeIDE.

According to the documentation, I should execute the following post-build command for CRC calculation:

STM32_Programmer_CLI.exe -sl D:\Projects\SW\STL_Test\Debug\STL_Test.elf  FlashStart@ FlashEnd@ FlashSectionSize

But the output in STM32CubeIDE-Console at building only shows:

  -------------------------------------------------------------------
                       STM32CubeProgrammer v2.20.0                  
      -------------------------------------------------------------------

Error: The safety lib command is missing parameters
make[1]: *** [makefile:102: post-build] Error 1
make: *** [makefile:63: all] Error 2
"make -j24 all" terminated with exit code 2. Build might be incomplete.

The problem likely lies with: FlashStart@ FlashEnd@ FlashSectionSize

If I manually enter values ​​there, the CRC calculation works, but not correctly (because nowhere is it precisely described what needs to be used or where the macros for start, end, and length come from)!

And that's my problem.

Nowhere in the documentation is there any mention of the parameters for Start, End, and Length for the CRC program.

Nowhere in the documentation is there any mention of Start, End, and Length for the firmware with flash testing.

I'm at my wit's end.

[AScha.3]

ask sidekick:

1. Determining Start, End, and Length Parameters for CRC in STM32

To set up the CRC calculation for your STM32 program, you need to define three key parameters: Start, End, and Length. Here’s how to determine each:

• Start: This is the address where your user program begins in flash memory. The start address must be 32-bit aligned and should coincide with the beginning of a flash memory section.
• End: This is the address where your user program ends. The CRC is calculated from the start to the end address. If the binary area is not aligned with the section size, the CRC for the last incomplete section is calculated only over the part that overlays the binary area.
• Length: This is the size of the area over which the CRC is to be calculated, typically computed as End - Start. The flash memory is divided into sections (e.g., 1 Kbyte each), and a CRC value is computed for each section.

Summary Table:

Parameter How to Determine

Start	Address where user program begins (32-bit aligned)
End	Address where user program ends
Length	End - Start (size of program area to check)

---

2. Flash Memory Region and Section Size Considerations

• The flash memory region for CRC calculation is defined by the start and end addresses of your user program.
• The memory is divided into sections (commonly 1 Kbyte each), and a CRC value is precalculated for each contiguous section.
• If the binary area is not aligned with the section size, the CRC for the last incomplete section is calculated only over the part that overlays the binary area.
• The CRC area is reserved in flash memory, and its size depends on the flash memory size, with each section having space for a 32-bit CRC pattern.
• The CRC start address can be calculated as:
  CRC_START = FLASH_AREA_END - (CRC size in bytes) * (number of memory sections) + 1.

---

3. Alignment and Section Size Impact

• Always align the start and end addresses to the section boundaries and ensure they are 32-bit aligned.
• The section size (e.g., 1024 bytes) determines the number of CRC fields and their placement in memory.
• If the binary area is not aligned with the section size, only the relevant part of the last section is included in the CRC calculation.

---

Summary

To get the parameters for Start, End, and Length for the CRC program in STM32:

• Set Start to the 32-bit aligned address where your program begins.
• Set End to the address where your program ends.
• Set Length to the difference between End and Start.
• Ensure alignment with section boundaries and consider section size for CRC field placement and calculation.

For additional support or to discuss your specific application with ST experts, you’re welcome to join conversations in STM32 forums.

Sources:

Collapse

UM2237_Rev28.pdf

[p. 120]

UM3267_Rev1.pdf

[p. 9]

UM3267_Rev1.pdf

[p. 10]

UM3267_Rev1.pdf

[p. 11]

1 of 100

[Christophe VRIGNAUD]

Hello @Heinz_Baumer,

In the command:

STM32_Programmer_CLI.exe -sl D:\Projects\SW\STL_Test\Debug\STL_Test.elf  FlashStart@ FlashEnd@ FlashSectionSize

FlashStart@ is the start address of the flash (not the user program)

FlashEnd@ is the end address of the flash (not the user program)

FlashSectionSize is constant and is always 0x400 (1kB).

The FlashSectionSize means that a 32-bit CRC figure is calculated for every 1kB section of flash. But the STM32_Programmer_CLI utlity uses the elf file to calculate the CRC only for flash sections containing actual code. It doesn't calculate CRC on empty flash.
Some examples of where the CRCs are located at the end of the flash is illustrated in Figure 4. Flash memory test: CRC use cases versus program areas and Figure 3. Flash memory test: CRC principle of UM3267. This document is for classB but the same flash test is used for 61508.

Note that the TÜV-certified X-CUBE-STL-H5 package is delivered under NDA and provided by the ST's local Technical Marketing Engineer. Support on 61508 safety is not done on STCommunity but through ST Online Support Center (Support Home - STMicroelectronics).

Best regards