Run 1 : Test First ROM Block Periodic Self-Test Thread Run 2 : Test ROM Block 2 Run 3 : Test ROM Block 3. This incident will lead to a self-test and recovery routine which also includes testing of all memory areas. Test on Exception: A fault of the system was detected (e.g. To reduce the run-time effects of the self-test on the application itself the ROM can be tested in smaller fractions of multiple intervals. Periodic Test: This will be executed periodically.
The Example 1 that accompanies this appnote shows a practical approach of this technique. They can be combined according to the requirements: Startup Test: This will be executed once at system startup and checks the full ROM area in question. There are three different run-time models that define when to test the checksums. This will be calculated at compile time and the application includes the same checksum calculation to verify this at runtime. A common practice for integrity check is based on a suitable checksum that is integrated into the ROM image.
7 Prerequisites To run through the workshop you need to install the following software: MDK-ARM Version 5 (any version) SRecord utility 1Ģ Fundamentals The self-testing of a systems ROM areas ensures that the tested application code and constant data is stored correctly and can be accessed by the CPU. 4 Adding block-wise Checksums using the SRecord Utility.
4 Use the Processed Hex File for Download and Debugging. Typically the built-in self-tests for microcontroller systems are separated into 4 categories: Bus self-test ROM self-test RAM self-test CPU self-test This application note discusses ROM self-test methods and their application in an MDK-ARM project. 1 ROM Self-Test in MDK-ARM MDK Version 5 Functional Safety AN277, May 2015, V 1.0 Matthias Hertel Abstract Self-Testing abilities are one of the most fundamental strategies to meet safety-critical system requirements.
0 kommentar(er)
