FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Data Corruption at Address 0x00 in MB85R4M2TFN-G-JAE2 FRAM After STM32U595ZJT6Q Reset

Sushant1
Visitor

‎2025-10-13 12:18 AM - last edited on ‎2025-10-13 9:14 AM by

Hello Community,

We are using an STM32U595ZJT6Q microcontroller and have connected an MB85R4M2TFN-G-JAE2 FRAM via a parallel interface. The setup works well under normal operation and even after a power cycle — all data is retained and verified correctly.

However, we are facing a consistent issue when performing a microcontroller reset (MRST) without power cycling the board:

  1. After MRST, the data at address 0x00 in FRAM is found to be corrupted (0xFF).
  2. All other memory locations remain intact.
  3. This issue does not occur on power reset — only on MRST.
  4. We observed that CS & WR pins go low for ~300 ns during MRST, which seems to be the trigger.

Below is waveform captured for the mentioned behaviour.

Sushant1_0-1760339662843.png

 

Below things we did so far:- 

  1. Added pull-up resistors on CS and WR line.
  2. Ensured early GPIO initialization in firmware to set FRAM control lines high.
  3. Verified that no write operations are performed in startup code.
  4. Checked FMC configuration and ensured no early access to FRAM.
  5. We observed this even when the controller flash is fully erased (No application code).

Despite all this, the issue persists — only address 0x00 gets overwritten with 0XFF after MRST.

 

It seems that on WARM reboot (keeping controller powered on) causes all GPIO pins to go LOW for approx. 5ns and 300ns rise time.

Has anyone encountered a similar issue with STM32 and parallel FRAMs? Are there any recommended hardware-level protections (e.g., latches, buffers, reset supervisors) or STM32-specific configurations to prevent this?

Any insights or suggestions would be greatly appreciated!

Thanks
Sushant Patil

0 Kudos
1 REPLY 1
mƎALLEm
ST Employee

‎2025-10-13 9:30 AM

Hello @Sushant1 and welcome to the ST community

Based on that statement:

 

@Sushant1 wrote:

 

 

We observed this even when the controller flash is fully erased (No application code).

Forget about FMC and FRAM for now and focus on the GPIOs. My question here: do you observe the same behavior on any GPIO pin no matter it's related to the FMC function and even the MCU is fully erased? 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
Top