Data corruption at address 0x00 in the FRAM memory after a STM32U595ZJT6Q Reset

[Sushant1]

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.

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

[mƎALLEm]

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? 

[Sushant1]

@mƎALLEm 

Thanks for reply.

Correction: - This thing happened only when FMC is initialized & we did warm reset. 

If we erased FW or we don't initialize FMC/FMCGPIO and perform warm reset pulse does not come on CS & WR pins.

On GPIO we are not getting any pulse on warm reset irrespective of MCU is programmed or blank.

[mƎALLEm]

Hello,

Ok we will analyze the behavior and get back to you for any feedback. Internal ticket number for follow-up 219725. Not accessible by the community members.

[Sushant1]

Hi..@mƎALLEm

There is update from our side.

When we do the deinitialized the FMC in running code the same pulse occurs on CS signal irrespective of MCU reset.

[mƎALLEm]

---

@Sushant1 wrote:

Hi..@mƎALLEm

There is update from our side.

When we do the deinitialized the FMC in running code the same pulse occurs on CS signal irrespective of MCU reset.

---

I don't think it's linked to the FMC peripheral but to the GPIO itself.

Anyway, it's under analysis and will update you as soon we have any news. I don't know how it will take but if you are hurry, I can propose the following as a workaround (you need to test it):

• The idea is to filter the first glitch on the GPIO alternate function (FMC_NEx).
• An OR gate (SN74LVC1G32) will be used with a pull-up resistor that pulls one of the OR gate inputs to high forcing the output to high during the reset period where the GPIO pins is in analog input (Hi-Z). No matter the FMC_NEx level, the OR gate output will be set to 1 protecting the memory to be selected by its chips select.
• Before configuring the FMC, a dedicated GPIO pin needs to be used and needs to be set to low then configure it to output push pull. At that time FMC_NEx level is already stabilized at high level and the memory chip select is not yet asserted.
• When the FMC starts to read/write from/to the memory, FMC_NEx starts to toggle according to these operations and the OR gate output will follow and the MCU can access normally to the memory.
• Need to take care of the OR gate propagation delay in the FMC timing config.