Accidental EXTI-Interrupts on STM32H735

[AZorn.1]

Hello,

maybe someone has an idea or can share an similar experience. Since I'm currently in the evaluation phase for selecting an MCU for our new industrial embedded project. I want to inspect and analyze this problem, to be sure the used MCU is working fine and i can use it (STM32H735IGK6).

Issue:
Pushbuttons on different EXTI-Interrupt  randomly fires twice or more times. Some GPIOs are effected, but not all, i have tested.

Setup:
Own PCB-Layout, 6 Pushbuttons, every one is debounced with 10kOhm and 10nF. Signal looks fine on scope, no bouncing can be seen with scope, absolutely clean signal.

Test 1:
apply a 200mHz sine-wave directly to the button pin. Expected behavior is: one interrupt on rising one interrupt on falling signal (due to the 200mV hysteresis on every input pin, as mentioned in datasheet). Behavior in RealLife: as soon as the voltage level on the pin reaches the switching thresholds of the input pin, i get lots of Interrupts (Rising and falling edge).
BUT now its getting freaky: if i turn off the running FMC access to an external RAM, instantly everything works as expected - only one single interrupt per transition.

Test 2:
same as above, but the FMC-access only bursts data every few seconds for approx. 250ms. Result: only, during FMC-access i get this accidential interrupts. (just to be sure: i checked the signal with the scope again: the waveform looks perfectly clean, without any noise, glitches, or something else)

I don't know if this can be an mcu-internal emc-issue or something like that, but fact is, if i enable the data transfer to the external RAM, the EXTI-Peripheral (or the schmitt trigger inside) gets extremely disturbed.
Of course, in this use case with buttons, a simple workaround is possible, but i also need a solution for other, more complex applications with combinations of FMC and EXTI (e.g. FPGA Communications, ...)

[FBL]

Hello @AZorn.1 

Try to monitor the VDD supply during FMC to check for noise due to simultaneous switching noise (SSN).

[AZorn.1]

Hello AScha.3,

i like the idea, to measure the voltage of the pin, when it is configured as output, for checking the internal power rail of the GPIO Peripheral.

Compare GPIO driven LOW - without and with FMC-Active:

 vs.

Compare GPIO driven HIGH - without and with FMC-Active:

vs.

noise is in both cases definitely more than nothing. The 3V3-supply-ripple, the noise on the pin and the noise on the power-rails in sum is with sure not that far away from the 200mV Hysteresis of the GPIO-Pin. Most of the noise effects the chip internally, so i think, with better filtering, or better layout you can't reach a really safe design with this mcu as long as the schmitt trigger hysteresis is that low.

You are right, that the 0.3 to 0.7xVDD (in my case 3.3V * .4 = 1,3V) - undefined area for digital pins is much higher the the 200mV Hysteresis, but if this sum of noise is the problem of this/my issue, wouldn't it be better to have higher Schmitt Trigger hysteresis (e.g. 500mV or even more)? Why isn't it designed higher?

I have never paid so much attention to a GPIO evaluation as I did with ST now. And I didn't need it either.

 

 

 

 

[AScha.3]

Hi @AZorn.1 ,

I see about 10mVss + 50mVss with FMC on gnd ; i am little bit surprised - i expected more. :)

Is cpu setup with slow/medium pin speed or hi ..? Would be interesting, to see "gnd " with highest pin speed , to compare effect.

+

btw Where is this 30kHz ripple on vdd coming from?  smps supply ?

+

Which pin/port is tested ? + on which group is FMC ?

Because cpu internal ground is not same on all digital ports + analog group (just guessing here).

Maybe  @STOne-32 could tell us about internal ground - if he likes...

+ see my last problem with a pin on H743 ->

https://community.st.com/t5/stm32-mcus-products/h743vi-pin-dies-away-reliability-problem-of-chip/m-p/638320#M235119

[AZorn.1]

Hello,

• this scopes are done on the original FMC setting with 133MHz and highest pin-speed.
• 30KHz ripple is from SMPS-supply,
• one of the affected pin is PB12 (on which i did de scopes above)
• FMC in my design is muxed as following:
  PD1 ------> FMC_D3
  PE0 ------> FMC_NBL0
  PE1 ------> FMC_NBL1
  PD0 ------> FMC_D2
  PG15 ------> FMC_SDNCAS
  PF1 ------> FMC_A1
  PF0 ------> FMC_A0
  PG5 ------> FMC_BA1
  PF2 ------> FMC_A2
  PG8 ------> FMC_SDCLK
  PG4 ------> FMC_BA0
  PF4 ------> FMC_A4
  PF5 ------> FMC_A5
  PF3 ------> FMC_A3
  PD14 ------> FMC_D0
  PD15 ------> FMC_D1
  PD9 ------> FMC_D14
  PC0 ------> FMC_SDNWE
  PD10 ------> FMC_D15
  PD8 ------> FMC_D13
  PC2 ------> FMC_SDNE0
  PC3 ------> FMC_SDCKE0
  PE14 ------> FMC_D11
  PF11 ------> FMC_SDNRAS
  PE8 ------> FMC_D5
  PG1 ------> FMC_A11
  PF15 ------> FMC_A9
  PF13 ------> FMC_A7
  PG0 ------> FMC_A10
  PE7 ------> FMC_D4
  PF12 ------> FMC_A6
  PE12 ------> FMC_D9
  PE13 ------> FMC_D10
  PE15 ------> FMC_D12
  PE10 ------> FMC_D7
  PF14 ------> FMC_A8
  PE9 ------> FMC_D6
  PE11 ------> FMC_D8

[LCE]

Just to make sure:

scope measurements are done without the ~10cm GND clip, but with the ground / spring / tip directly besides the "hot" contact?

[AZorn.1]

@LCEyes, with the spring-tip, to have GND loop as small as possible.
:thumbs_up:

[LCE]

Ah, spring-tip is the official name? Never used that in english... :grinning_face_with_sweat:

[FBL]

Hi @AZorn.1 

Can you store PB12 IDR values in an array with a while loop and see if it matches with the unexpected EXTI firing ?

You said that the 30KHz noise on your VDD is coming from SMPS. It is an external SMPS providing 3V3 to the MCU ?

Can you provide MCU VDD from another source for test purpose

Can you make sure there is enough decoupling on VDD as mentioned in HW getting started Getting started with STM32H723/733, STM32H725/735 and STM32H730 Value Line hardware development - section 9.3?

[AZorn.1]

sorry for my partially google-translated way of writing here.
What would you name this item:

[LCE]

I was rather laughing about myself, I think "spring-tip" is pretty good.

I would call it "Probe-Kontakt-Feder", beautiful "Denglisch". ;)