Introduction
More and more products on the market have safety requirements regarding their use. How to avoid danger to operators during use or reduce the probability of such dangers occurring is a key consideration for product safety. In this regard, related products need to pass safety certifications from relevant industries before they can be produced and marketed. For CLASSB and SIL certifications, ST provides corresponding software libraries and application manuals to assist customers in developing products that require safety certification.
During our support for customers, we found that they often encounter issues with Flash verification. Here, we have compiled common problems encountered and introduced how to configure the CRC calculation method for FLASH based on the two IDEs: IAR and KEIL.
Flash Self-Check Process
The Flash self-check generally consists of two stages: self-check at startup and self-check during program operation. Regardless of which type of self-check, the approach is as follows:
After the program compilation is complete, calculate the CRC value for the entire program, then append this CRC value to the end of the executable file, and burn the executable file with the CRC check value into the MCU. After the program starts, the self-check code in the program recalculates the CRC value based on the current Flash content (excluding the pre-stored CRC check value), and compares it with the previously calculated and burned CRC check value in Flash. If they match, the check passes.
The difference between these two self-check stages is:
The program startup self-check calculates the final CRC value for the entire actual Flash code range once; while the runtime self-check calculates the CRC in steps to avoid affecting the operation of other program modules, calculating one part at a time to eventually obtain the final CRC value. Issues surrounding Flash self-check can be categorized into two main types: one is whether the Flash range settings for the pre-calculated CRC value and the CRC value calculated after powering on are consistent; the second is whether the CRC algorithm used for the pre-calculated CRC and the one used after powering on are the same.
How to Add CRC Value
Next, we will mainly introduce how to add the CRC check value to the executable file.
Based on IAR Environment
If you are using IAR, the configuration for adding CRC values is relatively simple. By configuring the CRC calculation parameters in IAR, you can automatically calculate the CRC for the entire FLASH space and place the result at the end of FLASH.
1. Modify the Link File to Specify the Storage Location of the CRC Value
Add the following statement to the Link file to specify where the checksum is stored in FLASH. (Click on the image to enlarge)
This statement specifies that the CRC value is placed at the end of FLASH, which is at the end of the entire FLASH space, not at the end of the application code. Thus, the position of the CRC value is fixed and will not change with code size.
In the self-check code, you can read the CRC check value saved in Flash using __checksum to compare it with the recalculated CRC value.
2. Configure Parameters on the Checksum Page
After specifying the storage location for the checksum in the link file, you also need to configure the range and parameters for calculating the CRC value in the project configuration menu. See the image below (Click on the image to enlarge):
The IAR checksum page is divided into two parts.
The first part, outlined in red, defines the range in FLASH that needs to be calculated for CRC and the fill value for free bytes. Here, be sure to leave space at the end of Flash for storing the CRC value.
The remaining part is for setting the parameters for checksum calculation.
Checksum size：Select the size of the checksum (in bytes)
Alignment：Specify the alignment method for the checksum. Generally useful when the processor does not support unaligned access; if left blank, it defaults to 1-byte alignment.
Algorithm：Select the algorithm for the checksum
Complement：Whether to perform complement calculation. Selecting “As is” means no complement calculation.
Bit order：Order of bit output. MSB first means the high bits of each byte come first. LSB first means the low bits of each byte come first.
Reverse byte order within word： For input data, reverse the order of bytes within a word.
Initial value： Initialization value for checksum calculation
Checksum unit size： Choose the unit size for iteration, iterating by 8-bit, 16-bit, or 32-bit.
3. Configuration of STM32CRC Peripheral
Corresponding to the IAR checksum configuration shown above, the STM32 CRC peripheral can be configured as follows:
POLY= 0x4C11DB7 (CRC32)
Initial_Crc = 0Xffffffff
Input/output data not reversed
Input data: Set according to the actual Flash range, leaving space for the CRC check value
Initialization and calculation code for CRC peripheral (Click on the image to enlarge):
Based on KEIL Environment
KEIL does not provide direct functionality to generate CRC values, so external tools are needed to calculate the CRC value and then append it to the end of the executable file. The X-CUBE-CLASSB software provides a bat file that uses the external tool Srecord to generate the CRC check code for the entire Flash and place it at the end of the file. This tool can also be used with the standard peripheral library’s ClassB library. Now, let’s see how to use the Srecord tool in a KEIL project to add the CRC value.
1. Install the Srecord Tool
Download the Srecord tool (http://srecord.sourceforge.net). Copy srec_cat.exe, srec_cmp.exe, and srec_info.exe to a newly created directory C:\SREC.
2. Add crc_gen_keil.bat and crc_load.ini files to the same directory as the KEIL project
Open any KEIL project directory from the X-CUBE-CLASSB software package and copy the crc_gen_keil.bat and crc_load.ini files to your KEIL project directory.
crc_gen_keil.bat: Uses the external tool Srecord to generate the CRC check code for the entire Flash and place it at the end of the file.
crc_load.ini: This file is useful during debugging to configure the import of the HEX file with the CRC check code, avoiding program malfunction due to FLASH check failures.
The contents of these two files also need to be modified according to the new project path:
-
Change TARGET_NAME and TARGET_PATH in crc_gen_keil.bat to match the new project. Otherwise, the HEX file with the CRC check value cannot be successfully generated automatically.
-
The path and file in the Crc_load.ini file must also be consistent with the actual ones.
3. Define the Storage Area for the CRC Check Code
(Click on the image to enlarge)
In the scatter loading file, specify CHECKSUM at the end of the code. Unlike IAR, by specifying the checksum position with +last in the scatter loading file, it is not fixed at the end of the entire flash address but placed at the actual end of the code.
(Click on the image to enlarge)
4. Add External Commands to Automatically Generate a HEX file with CRC Check Value After KEIL Compilation
Define the HEX file path used for debug and flash download, using the HEX file with the CRC check value.
5. Configuration of STM32CRC Peripheral
Note that in the crc_gen_keil.bat file copied from the X-CUBE-CLASSB software package, set BYTE_SWAP to 1, which means that when calculating the CRC value, the input data is reversed byte order within a word.
Thus, directly using the HAL_CRC_Calculate function to calculate the result is incorrect. You can refer to the following code to initialize and perform the calculation:
(Click on the image to enlarge)
Alternatively, change BYTE_SWAP in the crc_gen_keil.bat file to 0, and you can directly call the HAL_CRC_Calculate function for the calculation.
Conclusion
This article describes the process of adding CRC check values based on IAR and ARM KEIL. Corresponding examples can also be found in the X-CUBE-CLASSB software package. If you encounter FLASH CRC check errors during debugging, do not panic. You can look for the cause from the aspects of whether the range settings for calculating the CRC value are consistent and whether the CRC algorithms used are the same. Be sure to test and observe the actual execution of the code, such as whether the address range to be tested matches the address range calculated during actual code execution, to prevent detection failures due to coding errors.