1. “SRAM Write Error” in the Errata ManualIn section 2.2.7 of the STM32G474 Errata Manual ES0430, the issue of SRAM Write Error is mentioned, with the following details:
▲ Figure 1. Explanation of SRAM Write Error in Errata Manual ES0430For SRAM larger than 32kbytes, each 32kbytes of space corresponds to one SRAM state machine. For independent SRAM spaces that do not exceed 32kbytes, such as SRAM2 and CCM SRAM, each corresponds to its own SRAM state machine. This is why, in the workaround, it is necessary to perform a state machine recovery operation for each space to ensure that each SRAM state machine operates normally.After the chip reset system starts, even if there is an “SRAM Write Error”, the first read operation on SRAM is not problematic (the read operation on SRAM can only recover the state machine corresponding to this address segment, without affecting the state machines of other address segments), and this read operation can restore the problematic SRAM state machine of this address segment to a normal state; if the first operation on SRAM after reset is a write operation, then the first write operation on SRAM will fail when an “SRAM Write Error” occurs. However, subsequent operations on SRAM will not have read/write issues due to the recovery of the state machine.2. How to Reproduce This IssueSince the startup code generated by the compiler initializes global variables, reproducing this issue requires performing the reproduction before the compiler initializes the global variables.The SRAM address segment where the “SRAM Write Error” occurs is the SRAM space that is being written to while also experiencing an abnormal reset.In the software engineering files, there will be a Startup code, for example, the IAR project for STM32G474 will have a startup_stm32g474xx.s file, and the processor first executes this part of the code after reset:
▲ Figure 2. Initialization CodeTo reproduce the issue, it is necessary to perform a loop write operation on SRAM right at the beginning of the Reset_Handler. This can be done using assembly code or C code; the C code can be placed in the SystemInit function, but care must be taken not to make function calls (function calls will push onto the stack, which means writing to the 32kbytes area of the stack, and the state machine corresponding to this space will recover to a normal state (in the case of an issue), making it impossible to reproduce the SRAM issue).By performing a write operation on SRAM while simultaneously performing an NRST reset operation on the MCU, the issue can be reproduced, with a probability of about one in a thousand, depending on factors such as the main frequency of the code execution and the frequency of the abnormal reset signal (this NRST signal comes from another development board or a signal generator).The judgment of the written data should be placed after the data is written.2.1. Workaround Code for STM32G474In section 2.2.7 of ES0430, a workaround is mentioned, and the following code is what needs to be executed first after the processor reset, placed at the beginning of the Reset_Handler:
UVISION---------------------------------------------------;SRAM addressMOV32 R0, #0x20000000;read accessLDR R1, [R0, #+0];next SRAM instanceMOV32 R0, #0x20008000;dummy read, no consequence on R1 valueLDR R1, [R0, #+0]MOV32 R0, #0x20010000LDR R1, [R0, #+0];the SRAM2 cutMOV32 R0, #0x20014000LDR R1, [R0, #+0];CCM SRAMMOV32 R0, #0x10000000LDR R1, [R0, #+0]▲ Workaround code used in UVISION project
STM32CUBEIDE-----------------------------------------------movw r0, #0x0000 //SRAM addressmovt r0,#0x2000ldr r1, [R0, #+0] //read accessmovw r0, #0x8000 //next SRAM instancemovt r0,#0x2000ldr r1, [R0, #+0] //dummy read, no consequence on R1valuemovw r0, #0x0000 //next SRAM instancemovt r0,#0x2001ldr r1, [R0, #+0] //read accessmovw r0, #0x4000 //the SRAM2 cutmovt r0,#0x2001ldr r1, [R0, #+0]movw r0, #0x0000 // CCM SRAMmovt r0,#0x1000ldr r1, [R0, #+0]▲ Workaround code used in STM32CUBEIDE project
IAR--------------------------------------------------MOV32 R0, #0x20000000 //SRAM addressLDR R1, [R0, #+0] //read accessMOV32 R0, #0x20008000 //next SRAM instanceLDR R1, [R0, #+0] //dummy read, no consequence on R1valueMOV32 R0, #0x20010000LDR R1, [R0, #+0]MOV32 R0, #0x20014000 //the SRAM2 cutLDR R1, [R0, #+0]MOV32 R0, #0x10000000 // CCM SRAMLDR R1, [R0, #+0]▲ Workaround code used in IAR project3. Probability Analysis of the IssueUnder normal circumstances, the probability of encountering an “SRAM Write Error” issue is very low, so many customers only consider the issue when it occurs. The “SRAM Write Error” is a very low probability event for the following reasons:1. The probability of an exception reset occurring on a running processor is relatively low. Furthermore, the probability of SRAM being in the writing phase during the reset is even lower, and the probability of the reset occurring while SRAM is being written and coincidentally causing an “SRAM Write Error” is further reduced.2. Most compilers have automatically generated Startup code, which initializes global variables (SRAM address space) to zero, causing the problematic SRAM state machine to return to normal (the “SRAM Write Error” happens to occur in this address segment).3. In typical applications, the code must run the startup code before reaching the main() function, and the first data pushed onto the stack will never pop until the code reaches the user’s own main function. Therefore, even if the first write to the stack space causes an SRAM write error, it will not affect this SRAM address segment.4. In bugzilla 167945, the following issue reproduction probability is mentioned: /*the problem arises when the product is reset (NRST signal) during a phase of writing into SRAM. I had a nucleo board constantly writing into SRAM while another nucleo was toggling its NRST pin. The first board was logging the cases when the reset was causing the problem. The test rig counted 188571 resets of STM32G4 to get 100 errors.*/5. In section 3.1 below, a situation that may cause “SRAM Write Error” could affect system operation. In some special cases, such as a Keil project found at a customer site, the first write operation to SRAM occurs during a stack push operation in the startup code, and this pushed data exists before jumping to main.c, making this pushed data useful. The existence of the “SRAM Write Error” issue may pose risks to program operation (customer code and tracking situation cannot be displayed here).3.1. Experiment 1 (IAR Project): To verify points 2, 3, and 5 above, the following experiment was conducted:Using STM32G474 development board: Nucleo_G474RE PCCompiler debugging software: IAR 9.40.1Software project: …\STM32Cube_FW_G4_V1.5.0\Projects\NUCLEOG474RE\Examples\GPIO\GPIO_IOToggleModify the main.c code as follows:
For SRAM space: 0x20010000, it belongs to global variables without initial values, and the startup code will perform a write “0” operation.For CCM SRAM space: 0x10000500, it belongs to global variables with initial values. When the “SRAM Write Error” occurs, there may be incorrect initial values. The disassembled code tracking is as follows:Trace information: Due to the presence of breakpoints, the system will stop at “Reset_Handler” after running, at which point the stack pointer points to 0x20000428, and then SystemInit is executed:
Step through the code and find that the first operation on SRAM is a stack push. See the following image for the first stack push:
After stepping through the code, the stack pointer is at 0x20000420, and the data in R0 and R1 is pushed onto the stack. Please note that this is a write operation to SRAM, and after the program runs to the main() function, it will never return, so this value will remain on the stack. Therefore, even if an “SRAM Write Error” occurs in this SRAM address segment, it will not adversely affect the program, and it can restore the problematic SRAM state machine to a normal state:
Then continue to track the code (the code is in the Startup code), looking for the first read or write position of each SRAM state machine address segment.The executed code flow is roughly as follows:If the corresponding MCU has an FPU, __iar_program_start will first call __iar_init_vfp to initialize the FPU: then __iar_program_start will call __cmain:
__cmain will first call __low_level_init:__cmain will then call __iar_data_init3 to initialize global and static variables:
__iar_data_init3 will first call __iar_zero_init3 to initialize global and static variables with an initial value of 0: then __iar_data_init3 will call __iar_copy_init3 to initialize global and static variables with a non-zero initial value: finally, __call_main will call the main function to jump to the main function:Thus, the MCU starts from the reset vector, runs the startup code, and then jumps to the main function, starting to run the user’s code:Tracking the code for SRAM operations, the following image shows the initialization (writing 0) of global variables without initial values, and the corresponding SRAM state machine can also return to normal (if there is an SRAM Write Error):
#pragma location=0x20010000 char Data1[16];
After the initialization of 0x20010000 is completed (all cleared):
Then it runs at full speed to the initialization of 0x10000500 (in this case, it runs to the breakpoint), since it has an initial value, the first operation on this address segment of SRAM is a write operation.
#pragma location=0x10000500 char Data4[4]= {0x11, 0x22, 0x33, 0x44};
Step through the code:
Step through the code:
Step through the code:
Step through the code:
Step through the code:
Step through the code:
Step through the code:
Step through the code:
Step through the code:
Since the previous value 0x44332211 has already been written, and it still exists after the program reset, when writing again, it will affect the tracking and judgment of the code. Therefore, we first write a value different from 0x44332211 into the memory window at address 0x10000500:
Then activate the disassembly window (by clicking in the disassembly window with the mouse) and step through the code, and you will see that 0x44332211 is written to the address 0x10000500 in the CCM SRAM.In this project, for the CCM SRAM space, it is the first write operation. If there is an “SRAM Write Error” issue, the program may run abnormally because a global variable has an erroneous initial value.If the program runs away and the customer enables the hardware watchdog, then after the watchdog resets, the program can run normally (the first write action has occurred, and the SRAM state machine is already normal).
Then the program continues to run until Main();:
We can see that after entering the main function, the previously pushed data will not pop out. In this project, the main function will never return, so for the 32kbytes address segment in this stack space, even if there is an “SRAM Write Error” issue, the system can still run normally.3.2. Experiment 2 (Keil Project): Using Keil project for the experimentUsing STM32G474 development board: Nucleo_G474RE PCCompiler debugging software: Keil V5.40Software project: …\STM32Cube_FW_G4_V1.5.0\Projects\NUCLEOG474RE\Examples\GPIO\GPIO_IOToggleThe running situation of the Keil startup code shows that the risk of “SRAM Write Error” in the Keil project is higher than in the IAR project because the Keil startup code first assigns initial values to global variables with initial values, and then performs the zeroing operation for global variables. If the stack space and this space for global variables with initial values are not in the same SRAM interval (32kbytes), there will be a problem. https://developer.arm.com/documentation/100748/0618/Embedded-SoftwareDevelopment/Application-startup
Modify the main.c code as follows:
Tracking the Keil software project: *.map file partial content: Global Symbols
In the assembly window, track the code execution. The following image shows the program starting from reset:
The first write operation to SRAM in Keil occurs during the stack push. Before the stack push:
After the stack push is completed:
Then continue to track the code:
Continue to track the code execution:
Next is the loading of global variables:If this part of the global variable space and the stack space do not belong to the same 32Kbytes SRAM space, then if there is an error in the first write to SRAM, it will cause code execution issues.
Continue to track the code,Next is the zeroing operation for test0 and others:
A large area is cleared:
Then jump to main.c, the previously pushed data has not been used. In the 32Kbytes SRAM space where the stack is located, even if the first SRAM write fails, there will be no problem.
4. Application Code RecommendationsFor some customers, the code is already stable and no longer modified, and it has passed testing; in product applications, a watchdog reset (hardware watchdog) is acceptable, and the code mentioned in the workaround section can be omitted.For customers who do not want to add this part of the code but are concerned about the impact of the “SRAM Write Error” issue on the system; they can analyze the specific addresses of global variables in SRAM based on the *.map file and track the execution of the startup code to see if the “SRAM Write Error” will cause issues in program execution. If there are no issues, the code in the workaround section can be omitted.For applications with high safety requirements, it is recommended to adopt the workaround code in section 2.2.7 of ES0430 to enhance system safety.For SRAM with enabled Parity check, regardless of whether there is a possibility of “SRAM Write Error”, it is recommended to initialize the entire SRAM memory at the beginning of the code to avoid parity check errors when reading uninitialized locations.
▲ For SRAM areas with enabled Parity check,it is recommended to initialize the entire SRAM area at the start of program execution5. SummaryBased on the actual usage of customers, they can choose whether to use the workaround code for “SRAM Write Error”. However, for applications with high safety requirements, it is still recommended to use the SRAM state machine recovery code (the workaround mentioned in section 2.2.7 of ES0430, or section 2.1 of this article), and to initialize the SRAM area with enabled Parity check at the start of program execution.
END
Source:STM32
Copyright belongs to the original author, if there is any infringement, please contact for deletion.▍Recommended ReadingWhy is C++ rarely used in microcontroller development?Xiaomi is really stingy, a single MCU can handle all functionsUpload a PCB photo with only 2 lines of silk screen, GPT-5 helped me solve everything!→ Follow for more updates ←