NXP Semiconductors EVKmimx8mm, Руководство пользователя, Страница: 23 / 26

The post-build calculation is different for each IDE:
In the IAR IDE, the CRC is calculated by the IDE directly using the linker (see Options->Build Action). The Flash test is fully
integrated to the example project in the IAR IDE. It is necessary only to turn this test on in the
safety_config.h
file.
In the uVision Keil IDE, the CRC is calculated by the Srecord third-party tool, which is called from the IDE (see Options → User
→ After Build) The Flash test is fully integrated to the example project in the uVison Keil IDE. It is only necessary to turn this test
on in the
safety_config.h
file. In case of any issues, see Arm uVison Keil IDE postbuild CRC
In the MCUXpresso IDE, the CRC is calculated by the Srecord third-party tool. The user must do some additional steps. For more
information, see
MCUxpresso postbuild CRC .
The invariable memory test example uses the
crc.bat file for post-build calculation, so this example does not work
on a Unix/Mac operating system.
NOTE
When you debug your application with the Flash test turned on, be careful when using the breakpoint. The software
breakpoint usually changes the CRC result and causes a safety error.
NOTE
6.5 Variable memory test
The variable memory on the supported MCU is an on-chip RAM.
The RAM memory test is provided by the MarchC or MarchX tests.
The test copies a block of memory to the backup area defined by the linker. Be sure that the BLOCK_SIZE parameter is smaller
than the backup area defined by the linker.
This test cannot be interupted.
NOTE
6.6 Program counter test
The CPU program counter register test procedure tests the CPU program counter register for the stuck-at condition. The program
counter register test can be performed once after the MCU reset and also during runtime.
The program counter test cannot be interrupted.
NOTE
6.7 Stack test
This test routine is used to test the overflow and underflow conditions of the application stack. The testing of the stuck-at faults in
the memory area occupied by the stack is covered by the variable memory test. The overflow or underflow of the stack can occur
if the stack is incorrectly controlled or by defining the "too-low" stack area for the given application.
Choose a correct pattern to fill the tested area. This pattern must be unique to the application.
NOTE
6.8 Watchdog test
The watchdog test provides the testing of the watchdog timer functionality. The test is run only once after the reset. The test causes
the WDOG reset and compares the preset time for the WDOG reset to the real time.
For this test to run correctly, it is necessary to keep the WDOG_backup variable in a part of memory which is not corrupeted by
the WDOG reset.
Variable memory test
i.MX8M Safety Example , Rev. 3, 07/2021
NXP Semiconductors 23