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 

Did you succeed to reproduce on discovery board. If so, please don't hesitate to share with us here in public or in private message your software and your hardware setup preferably on our reference board. This would be helpful to investigate further this issue. For now, unfortunately, we cannot confirm an issue linked to the chip.

[AZorn.1]

Hello F.Belaid,

thank you.

I had a look on the H735-disco schematics and found out, that on this board there is no external SD-RAM or something else connected to the FMC Interface. So i can't easily port my software to this hardware.

Maybe i can figure out other issue-triggers, which i can activate also on the Disco board.

By now, i can run my/this software in the discoBoard, but without the FMC-Access. And of course EXTI on other pins, because only a few pins are unused at this board.

[LCE]

Your PCB screenshot looks quite good and professional, but there are many close copper traces, so I can imagine there could be some crosstalk. Especially if the debouncing Rs & Cs are close to the buttons (where they should be), but the deciding factor might be what's happening at the MCU pin (maybe try some stronger / weaker external pull-ups).
Just to make sure, every pcb signal layer has a neighbouring low impedance plane layer connected to ground or VCC? No gaps in the planes?

Until now I have used quite a few ST test boards, incl. Nucleo-H723 and H735-disco, I never had these problems, and some of the boards have a terrible layout (due to the fact that a Nucleo's pins have many options), and my firmware did quite some stuff (ETH, OSPI HyperRam, SAI, I2S).

Have you checked that you are not double-using some EXTI / FMC pins?

I cannot imagine that this is a STM32 problem. But who knows...

[AZorn.1]

Hello LCE,

thank you for your valuable input. Crosstalk from other pins was also one of my attempts so i used my (of course not the fastest one) to inspect the problem-trace.

Coupling was AC to filter the DC-part and to bring the signal down to GND, for better scoping. GND-Spring to have lowest possible GND-Loop (only few mm) to reduce extra noise due to the scope probe. And i scoped the via, directly near to the BGA, not to miss anything.

first one is without FMC-communication

second one with running FMC-communication (Be careful, it looks worse than it is due to the "Persistance-overlay" view of the scope.)

so, of course the noise level rises, but all within +/-20mV compared to the 200mV pin-hysteresis, i would say, this can not be the cause. It should be an easy one for the Schmitt trigger to filter this small noise.

Since the processor isn't the latest, I would be surprised if there was a defect in the silicon. And above all, no one has had similar problems with it before, so far google knows it ;-).

I'm sure this use case is very contrived and not a real problem, but I don't know what to do now. If I design another evaluation board, I have no idea what to change to prevent such problems, or how to ensure that no more/other pin sampling problems occur, since any input pin/peripheral can be affected.

[TDK]

Looks like some combination of cross-talk and internal noise to me.

Would be interesting to see if you can change the EXTI pins to ADC at very high sample rate and see if their input also varies considerably more when FMC is going. Probably they will.

Layout is good, perhaps decoupling caps could be closer.

What are your RC values? If you use a lower-pass filter, do these jumps disappear?

> I have no idea what to change to prevent such problems, or how to ensure that no more/other pin sampling problems occur, since any input pin/peripheral can be affected.

Keep in mind input pins have a relatively large uncertainty zone (from 30% to 70% of VDD), way more than 200 mV. 40% of 3.3 V is 1.32 V. Might not be that big of a problem. Taking digital inputs on slow moving analog signals is not a very common use scenario.

[AZorn.1]

Hello,
thank you, for your input.

Today a had a look on this issue again, i found out, that all, for me accessible pins, can unfortunately not be measured by the ADC so i can't check this.

GPIOs, configured as analog IN (default after reset) have disabled Schmitt-Trigger but are forced to 0 in inputDataRegister. For me, the behavior still looks, as the Schmitt-Trigger would be disabled in case of FMC-usage too, but not forcing the IDR to 0.

I can't imagine that mcu-internally the cross-talk/noise is that high, that the Schmitt-Trigger hysteresis of 200mV is exceeded.

[TDK]

> For me, the behavior still looks, as the Schmitt-Trigger would be disabled in case of FMC-usage too, but not forcing the IDR to 0.

I don't think the hardware has the capability. The schmitt trigger and IDR are inextricably linked since IDR is after said trigger.

[AScha.3]

Hi,

1. your (6 layer?) board looks ok, signal on scope is perfect like a dream.

2. EXTI "error" switching away, when FMC not active.

-> exti-pins "see" signal (spikes), so on-chip-GND is not the same, you see on scope.

(These H7 are damned fast switching...i know this from other "curious" effects. This will create some "ground bounce" on-chip ! )

--> Try : setting all FMC outputs/pins to medium or low drive speed, depends on your speed for FMC, try little bit low speed , to prove this.

:)

btw

the medium setting still can work up to 80...100MHz :

[AZorn.1]

Hi AScha.3,

thank you for your suggestion.

I gave it a chance and tested the com with 12.5Mhz (instead of 133MHz) with EVERY pin in lowest speed mode.

Same behavior, but with lower speed on RAM access. Lot's of additional and unwanted pin-changes.

Maybe the lines coming from RAM still produces the noise because i can't configure driver strength on the external chip.

[AScha.3]

Hi,

your right - if the other chip is same fast switching, it still producing the spikes.

You can check this very easy (if you have the SA ..) : connect EMI current probe to SA input and look on the board area...

I had this (similar) problem, when connecting a TFT to H743 - only damping resistors (33...80 ohm) in all lines helping then. -> It works, but still emission in ...1,5GHz range on the cable to the TFT .

The manufacturer of the TFT realized this also (but didnt tell anything) - next version of TFT has resistors and no more heavy EMI emission. :)

+

To check on your board : set the "bad" exti pin -> to gpio out, low . Then remove the filtering cap on the line and look with scope, whats coming out from "there" . You might see, whats the internal "gnd" doing , compared to gnd outside.

Just to know: is this the problem - or something else...

just for fun:

simu, what will be internal gnd bounce, at 3pF pin capacity and about 20mm from chip to gnd (= about 20nH line)

surprise, surprise : at 1ns rise/fall times you might get +/- 1V spikes...sure enough to trigger 200mV sm levels.

(= thats external 1ns rise/fall driving the 3pF pin capacity... )

Now if you optimize layout..and get real distance chip-gnd to 5mm -- 5nH :

-> stll 450mV spikes

Now 5mm with 51 r in line :

yepp. 200mV max spike.