cancel
Showing results for 
Search instead for 
Did you mean: 

Differences in Flash Error Occurrence by Code Location(SRAM,DTCM) in STM32H7

Odoong
Associate II

Hi, I found a pretty interesting issue while developing an STM32H7 Series MCU.

And I tried many things to figure out the cause but failed. T^T

 

If you have experienced similar symptoms or know anything about them, I hope we can discuss it together here.

 

Subject : Differences in Flash Error Occurrence by Code Location(SRAM,DTCM) in STM32H7

Model : STM32H7A3ZI

Spec : Internal Flash Memory  (2MByte / Bank 1,2 each 1MBtye)

            Internal SRAM (1MByte)

            DTCM (128KByte)

            External RAM

 

 

I wanted to be able to erase the Flash area where the code was loaded during code execution(for a Firmware Update), so I followed the steps below.

 

First, store the Binary File in a Buffer located on the external Ram, and verify that it is normal.

Second, execute the code I designed and perform Flash Erase/Write with the corresponding buffer data.

Last, reboot the system when flash write is compete.

 

Here, the code is based on the HAL code provided by STM, and only slightly modified as needed. (For example, changing to Wait by Count Up, an internal variable, rather than Tick during Wait operation, etc.)

 

Now, when I put that code (executive file .O) in DTCM and repeatedly test it, I occasionally get a flash error (usually an RDP error ). The frequency of errors was random, but it was about once every 50,000 times. In the event of this error, all Flash operations are blocked without additional action, which is fatal to the system.

However, when I placed the same code in SRAM and performed iterative test, no problem was found.

 

I've solved the problem, but I'm posting this on the community because I want to find out the cause. Any opinions are helpful to me. Please feel free to give me your opinion. Thank you.

4 REPLIES 4
TDK
Super User

The issue you're running into is likely something specific to your code rather than something applicable at a more general level. You should never see "RDP errors" occur. Though 50,000 cycles through flash is a crazy amount. The flash is only rated up to 10 kcycles.

If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Super User

At which step do you see the "RDP error" : erase or write? 

Do you use the MPU settings against the famous "speculative execution bug"?

Indeed 50K cycles is crazy. In any case, failure should be expected and handled, even though it is less probable.

Also, executable code is meant to run in ITCM rather than DTCM. There's some subtle difference in the bus paths.

 

 

Odoong
Associate II

Yeah, I've seen that in the document about Flash life. But I know that's what STM guarantees, and what actually works is much longer than that. (It actually tests more than that.)

But this is the problem. An error occurs when the code is loaded into the TCM, but not in the SRAM.

Isn't it weird?

1)Do you use the MPU settings against the famous "speculative execution bug"?

Actually, I don't understand this exactly, but the first thing I suspected was by the MPU.

But as far as I know (unless it's enforced by Default) I didn't set up the MPU.

I would appreciate it if you could tell me about the specific execution bug you mentioned if there is a forum I can refer to.

 

2) At which step do you see the "RDP error" : erase or write? 

That's the fun part. When you connect ST-Link to the flash error, it happens when you perform the Flash Write function and when you perform the Erase function. That means the point of occurrence is random.

 

3) Also, executable code is meant to run in ITCM rather than DTCM. There's some subtle difference in the bus paths.

If what you said was correct, I was mistaken. I understood that both DTCM and ITCM can load executable code, but there is only a difference in what function is specialized for. The chip I used only had a single chunk of memory called TCM, so I'm not sure if that's ITCM or DTCM. But if it was DTCM, it could be the cause.