Strange, unexpected behavior of memory bus pins during reset – silicon bug in STM32H743I rev. V

[EngyCZ]

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.

[EngyCZ]

Yes, nWE is at PD5, configured as Push-Pull, no pull-up/pull-down, very high speed.

[Pavel A.]

Very high speed = very high strength, potential of noise and ringing.

[AScha.3]

So try with a hardware pullup (10k ?) on PD5 , speed at low.

[EngyCZ]

We don't have problem with noise or ringing. But I measured it.

Since we also have 20ns RAM on the bus, we need High or Very high speed.

Very high

High

Medium

[EngyCZ]

Yes, of course.

Without 10k pull-up

With 10k pull-up

Glitch to 0V is very strong.

[AScha.3]

Strange...

so if you dont need hi speed on the nWE , but on PD5 want hi speed,

you could put a resistor + cap in the line to nWE , preventing fast spike just for this ,

and let PD5 on hi speed setting.

[waclawek.jan]

Thanks for the results with nRST. I now see that we are down at the nanoseconds realm.

If you are willing to experiment further, let's make a similar assumption then what @Bassett.David made above, i.e. that some portions of the whole circuitry reset faster than GPIO_MODER into Analog: let's assume that GPIO_AFR[] resets faster, disconnecting the pin driver from FMC itself (I presume that FMC wouldn't drive those pins to 0 under reset, an assumption which may be false, too). Now most of those pins don't have an explicit setting for GPIO_AFR[]=0, but I've seen cases where even if this was the case, some of the other signal sources was in fact connected.

So my experiment would be, to set given pins - while still being AF in GPIO_MODER - to GPIO_AFR[] = 0; and then try to experiment with the peripherals which are at the same pin, whether any of them would drive the output pin high. If it would, then I'd try to revert the pin to FMC while retaining that setting of that "other" peripheral, and invoke the reset.

I know it's a slim chance this would work; but let's be honest, what's the chance ST will provide a workaround here, or, more precisely, given the nature of the problem, what's the chance there *is* any sane workaround here.

JW

[EngyCZ]

Thank @waclawek.jan for the suggestion.

On PD5 there is

AF2 - HRTIM_EEV3

AF7 - USART2_TX

HRTIM_EEV3 is the input signal for High resolution timer.

USART2_TX is Transmit Data Output for USART2, and according to the datasheet TX pin idle state is High.

I'm still waiting for the official ST statement @Amel NASRI.