Issue with STM32F107VCT6 Data Corruption when Resetting nRESET

[NS]

Hello,

I am using the STM32F107VCT6 microcontroller and, under normal circumstances, it works flawlessly. However, I have been encountering an issue where data in a specific memory area becomes corrupted when I toggle the nRESET pin at 2-3 second intervals. I would like some advice on how to resolve this problem or identify its root cause.

Any guidance or suggestions on addressing this issue would be greatly appreciated. Thank you in advance.

Best regards,

[jiangfan · Accepted solution]

one question: flash write operation enabled in your code?

if the answer is no, the behavior is strange.

[NS]

If this is regarding a question about Flash write operations and Lock/Unlock, we always perform memory protection as a standard practice. We have verified this aspect several times, and it appears to be in order.

However, it seems that a hardware reset through nRESET during booting might be affecting the Flash memory. I'm uncertain about what specific areas to check in this context. Could you provide guidance on what we should investigate or be aware of in such cases?

Your assistance would be greatly appreciated.

[jiangfan]

Well, if I understand correctly, your code really enables flash write operation.

Imagine hardware reset happens during flash write operation (erase or program), flash content will be corrupted. We can't avoid such situation. But we can detect such situation by using something like CRC and avoid using the corrupted data. And we can recover the corrupted state by erasing the corrupted data area.

[jiangfan]

If hardware reset is due to power loss, perhaps backup power supply may be added to avoid such case or minimize the negative impact.

[NS]

Thank you for the clarification.

It appears that enabling Flash write operations in our code might indeed be causing the issue. In the event of a hardware reset occurring during a Flash write operation (erase or program), it's understandable that the Flash content could become corrupted.

Your suggestion of using a CRC (Cyclic Redundancy Check) to detect such a situation and subsequently avoiding the use of corrupted data is a valuable insight. Additionally, the idea of recovering the corrupted state by erasing the affected data area is a practical solution.

We will investigate further and consider implementing these measures to handle the situation. Your input is greatly appreciated.