Strange, unexpected behavior of memory bus pins during reset – silicon bug in STM32H743I rev. V
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-23 3:49 AM
Hi.
We found a serious problem in the behavior of the memory bus pins during reset.
Our design uses an STM32H743I CPU and non-volatile MRAM/FRAM memory connected via a bus. We use the FMC controller to access the memory, the bus pins are set up, and everything works. We have pull-up resistors on the nE[x] (chip select), nOE (output enable) and nWE (write enable) pins so that the correct levels are present on the memory inputs when the CPU starts. The problem occurs during a reset triggered, for example, by a watchdog or a reset button, when a negative glitch appears on these pins, causing an unwanted write to memory.
We have the same HW design equipped with STM32743I rev. Y (older than rev. V), where this problem is also manifested to a lesser extent and pull-up resistors compensate for it, but with rev. V the manifestation is significant.
The following are measurements on rev. Y and rev. V. We used the FMC_SRAM example from STM32Cube_FW_H7_V1.12.0, so we believe the FMC is initialized correctly.
Our HW with STM32H743I rev. Y (Similar measurements were observed on the STM32H743I-EVAL board with rev. Y)
PD5 – nEW – glitch from 3.36V to 3.12V
PD7 – FMC_nE1 – no glitch, stable 3.36V
PG9 – FMC_nE2 – no glitch, stable 3.36V
PG10 – FMC_nE3 – no glitch, stable 3.36V
PG12 – FMC_nE4 – glitch from 3.36V to 2.48V
Our HW with STM32H743I rev. V
PD5 – nEW – glitch from 3.36V to 0V
PD7 – FMC_nE1 – glitch from 3.36V to 1.84V
PG9 – FMC_nE2 – glitch from 3.36V to 2.12V
PG10 – FMC_nE3 – glitch from 3.36V to 1.52V
PG12 – FMC_nE4 – glitch from 3.36V to 0V
From the documentation: “During and just after reset, the alternate functions are not active and most of the I/O ports are configured in analog mode“. So it looks like when the I/O pin is transitioning to the default state, the output is set to 0 for a while.
I would like to ask ST to investigate the problem, provide a SW workaround and mention the problem in the Errata document.
- Labels:
-
Bug-report
-
FMC-FSMC
-
GPIO-EXTI
-
STM32H7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-04-30 9:24 AM
Hi @EngyCZ ,
Interesting case where I don't have really a full explanation. But I would have a proposal to explore: is it possible for you to decrease the value of the external pull-up resistor on some pins where you noted the glitch? Does this have any impact?
-Amel
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-01 6:19 AM
Hello EngyCZ,
I have no answer but wondering if writing these pins with "1" as GPIOs before enabling FMC control would make a difference? Perhaps they "fall back" to the output register value as the FMC is disconnected during reset. Hopefull I realize, but worth a try?
Regards,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-01 11:34 AM
This chip has the nWE pin not for nothing. What if you link it to NRST so that write automatically gets disabled in unfortunate moments?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-05 12:47 AM
Hi @Amel NASRI
Yes, we tried decreasing the value of the external pull-up resistor, but it had almost no effect on the glitch size. It only reduced the return time to 3.3V.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-05 12:49 AM
Yes, we tried that too, but it had no effect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-05 12:52 AM
Hi @Pavel A.
We measured the sequence of nWE and nRST pins and the nRST signal is activated much later, after the problems on the pins I described.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-05 1:54 AM - edited 2025-05-05 2:33 AM
Hi @EngyCZ ,
> We measured the sequence of nWE and nRST pins and the nRST signal is activated much later, after the problems on the pins I described.
This is intriguing, as it defeats the very purpose of the nRST output signal (as a way to convey the internal reset signal to other circuitry). Here you are talking about the case when nRST occurs from "inside" the mcu, such as watchdog, I presume.
Would you have waveforms taken for this issue, can you please post them.
Also, what exactly is connected to nRST?
Sorry I have no comment relevant to your main issue.
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-05 4:12 AM - edited 2025-05-05 4:14 AM
Hi @waclawek.jan & @Pavel A.
OK, a small correction. The voltage on the nRST pin starts to decrease simultaneously with the nWE glitch. However, it is not as fast as nWE probably because of the capacity 100nF on the input.
Thus, in the "digital" world, nRST switches to 0 later than nWE.
nWE - Yellow, nRST - Blue
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2025-05-05 4:36 AM - edited 2025-05-05 5:11 AM
Which pin is nWE, PD5? how it is configured (strength/speed, PU/PD) ?
