Research on Self-Detection of SRAM Cell Fault Software in ARM Cortex-M3

　　Introduction

　　At present, the research on storage unit SRAM is based on hardware circuits, and these methods are used in the production process, but the production process cannot completely eliminate SRAM hardware failures. During its use, if the SRAM hardware fails, it will cause program errors and it is difficult to detect. Therefore, in the application stage, in order to prevent the storage unit from being damaged and causing system errors, it is necessary to detect SRAM through software.

　　1 SRAM operation status analysis

　　SRAM is used to store non-CONSTANT variables (such as RW), which have the characteristic of being lost when power is off. From the startup steps of Cortex-M3, we can know that after the system is powered on, the first 5 steps of reset are executed:

　　①NVIC reset, control core;

　　②NVIC releases the core from reset;

　　③ Kernel configuration stack;

　　④ Kernel sets PC and LR;

　　⑤Run the reset program.

　　It can be seen that the SRAM cannot be tested after the C environment is called in, but must be tested before the Cortex-M3 is reset and after it is started.

　　Before executing the last step of system reset, the system does not perform any related data transfer actions on SRAM. Step 5: Run the reset program. There is a reset subroutine in the startup code of the STM32 series microcontroller with ST's Cortex-M3 processor core: __main is imported in this subroutine, which is the entry address of the C library file. It executes the following 3 steps:

　　①Copy non-root (RW, RO) from Flash to SRAM;

　　② Allocate the ZI area and initialize it to 0;

　　③Jump to the stack initialization subroutine interface __rt_entry.

　　From the first step of __main, it can be concluded that after jumping into __main, the system performs relevant data transfer operations on SRAM. Therefore, the SRAM must be checked before this step, otherwise the data transferred from the Flash to the SRAM will be overwritten.

　　2 SRAM detection scheme design

　　Before the reset subroutine jumps into __main, another program entry SRAM_Check is designed to make the PC pointer point to the entry of the hardware unit detection program (SRAM_Check) for the SRAM. In SRAM_check, first point the PC pointer to the first address of the SRAM and write 0xFF, read the value of the address back to the general register Rn1, and add 1 to the value in Rn1, then compare Rn1 with 256 to determine whether the SRAM hardware is damaged. This operation can avoid errors in the algorithm itself due to the SRAM hardware always being 1 or 0. Since the default clock of the Cortex-M3 after reset is HSI, which is an internal RC oscillator, the accuracy is not high. If a more accurate and faster clock is required, the relevant registers must be operated before jumping into SRAM_Check. [page]

　　3 SRAM detection software design

　　Figure 1 is the SRAM detection software program flow designed in this paper.

　　4 Online debugging results and analysis

　　After power-on reset, the initial SRAM value when the online debugging PC pointer points to the Reset_Handler entry address is shown in Figure 2. It can be seen that the value of each SRAM unit is 0x00 when the system is reset.

　　Under online debugging, Figure 3 shows the SRAM value after all SRAM addresses are tested, which fully meets the program design requirements. After the SRAM test passes, all SRAM is released and restored to 0x00, as shown in Figure 4.

　　5 Conclusion

　　This paper proposes a software-based SRAM unit fault self-detection method. The results obtained through online debugging show that this method is completely feasible. In practical application, this method can ensure that the system runs normally in a reliable environment. If the SRAM unit is damaged during production or transportation, it can also be easily detected by this method, greatly reducing the time for system troubleshooting.