Reset button debounce on Pi [solved]

[mwolter]

Having an issue with connecting the reset pin of the M0 to a GPIO port from a Raspberry Pi. Is there a way to make the reset pin less sensitive? Any voltage fluctuation of 50ns or more causes the M0 to reset.

I've noticed a bounce issue on the reset button itself. On occasion, pressing the reset button puts the M0 it into boot loader mode. This should only be possible if pressing the button twice.

More Details
The reset pin on the M0 is connected to a GPIO pin in the Pi, and is normally kept high by the Pi. To reset the M0, the pin is brought low for two seconds, then returned high. This seems to work fine.

The Reset pin sensitivity issue appears when there is any fluctuation in the voltage passed by the Pi. In my setup, there are three GPIO pins used on the Pi, two are connected to a relay module and one is to the M0 reset pin. Intermittently, when one or both of the relays are cycled, there is a short voltage ripple on all GPIO pins from the Pi and this causes the M0 to reset. The relay module I am using is optoisolated and uses a completely separate and dedicated 5v supply. I've also shielded and earth grounded all cables around and leading to the relay to minimize EMI. I believe I have isolated and protected the Pi as good as possible from feedback and interference.

[Felix]

I've noticed a bounce issue on the reset button itself. On occasion, pressing the reset button puts the M0 once puts it into boot loader mode. This should only be possible if pressing the button twice.

I haven't noticed that, but I guess it's possible. The RESET button is connected to the RST pin of the SAMD21 without any hardware debouncing. It's meant to reset the board and/or put it in bootloader mode (by double tap). If if ever does go into booloader, tap RESET again.

Having an issue with connecting the reset pin of the M0 to a GPIO port from a Raspberry Pi. Is there a way to make the reset pin less sensitive? Any voltage fluctuation of 50ns or more causes the M0 to reset.
...
The Reset pin sensitivity issue appears when there is any fluctuation in the voltage passed by th Pi.

Not sure what you mean by voltage fluctuation. Have you scoped this?
Anyway, both are 3.3V systems. Assuming there are no ground loops or different supplies. The RST pin is pulled up by a 10K resistor, as seen in the schematic. A nice clean edge from another system should cleanly reset it but I haven't tried this with a Pi. If there's noise in the Pi side ... and we've heard about that before ... then I think you're doing all you can already to avoid that already.

[mwolter]

Yes not sure there is anything else I can do. I have tried typical debounce methods with a capacitor and another with a Schmitt trigger and even went as far as putting all three GPIOs behind transistors but but occasionally the voltage fluctuation causes the M0 to reset. The reset pin is SUPER SENSITIVE. I think the easiest solution is to add another relay solely for this reset function. Definite overkill but it should work.

Yes, I’ve scoped it and see a +-3v sinusoidal ripple that lasts about 90ns.

Is there anything that can be done in code? Maybe a register or boot loader change that could help?

[Felix]

Yes, I've scoped it and see a +-3v sinusoidal ripple that lasts about 90ns.

Whoa!! No wonder. Where's that coming from?

[mwolter]

From the Pi, timed almost exactly as the relay activates (Pi GPIO pin goes low).

It occurs only when mains voltage is connected to the relay, when mains is disconnected and the relay is cycled, the pulse has never happened. I believe this is because there is a slight load on the relay's mains output and the relay is activating when the main's voltage sinusoidal voltage is at or close to +110v or -110v because only about one in five activations of the relay triggers the pulse. Took me a while to track it down and tried many things to mitigate the pulse but I believe it's causing the Pi to momentarily reset all GPIO pins. I can reduce the pulse with a resistor and a charge cap to the point where my scope doesn't trigger but the M0's reset pin is so sensitive it can sense it no matter what I do.

The reset pin is so sensitive that connecting a jumper with nothing connected on the other side, triggers a reset!

Tried a Pi 3B, a Pi 3B+ different relays as well as many other things and the reset issue is reduced but never eliminated. It doesn't appear to be affecting the other channel on the relay so I believe relays are immune to the short pulse and a third relay dedicated to M0 reset might be the best solution. Not ideal, but I think it should only trigger when the pin goes low and not on the pulse.

The issue seems to be very weird, as there are few posts on the internet regarding this but I think the combination of this pulse and the M0's reset pin sensitivity are pretty unique.

One other idea I had is an electronic circuit who's output only goes high(or low) when it's input is triggered for a period of time. If this period of time is longer than the pulse it would mitigate the issue.  This is easy programmatically but it needs to be hardware. Do you know if a circuit like this?

[Uncle Buzz]

Not sure if it covers all your requirements, but you can read the datasheet of STM6600, it's a push button controller with debouncing function.

[Felix]

Sounds like the problem (which still isn't clear but sounds like AC noise) is somewhere else not in the M0/SAMD21.
I've never seen random resets because of ambient noise, or being hand-touched while powered, and I played with these for about a year now. Flawless, as expected from a robust MCU that works well in DC situations. I would be curious to see what happens with another type of MCU under the same conditions. Or even a similar MCU based board, Arduino Zero?

Anyway I am not surprised at all that a DC circuit is ultra sensitive to a 3Vpp (ac coupled?) sine pulse.

[perky]

I'm not sure either whether the Pi's GPIO pin's drive strength can be changed in firmware, but it sounds much like noise on the Pi's 3.3V IO power supply for it to cause noise like that on it's GPIO pin. If you've tried filtering on the RESET signal, the noise would seem to be coming directly from a low impedance source i.e. the GPIO pin itself. Can you correlate the noise to any dip on the pi's 3.3V IO supply?

Mark.

[mwolter]

Thanks for the suggestions everyone. Here's an update. I believe I have narrowed it down a little further.

Installed a relay on the Pi GPIO that connects ground to the M0 reset pin when closed and the issue still occurred. No real help.

The last place I could think of was the power supply for the M0. The issue appeared to come from the Pi but who knows, seemed like it was worth a try. The M0 was powered by a USB hub with 2 amp output which served two purposes, power and USB communication for sketch upload. Moved it to the Pi 5v rail and the issue was immediately better. Still did it every now an then but far less frequent. My theory is that when the relay engaged with a slight load, it was casing a slight mains fluctuation that was affecting the power supply for the Pi and M0 differently and caused an oscillation on the outputs at different frequencies. Moving the M0 to the Pi power rail effectively put them on the same power supply which in turn put it on the same oscillation frequency.

It could also be that the power supply for the USB hub is more susceptible to mains fluctuation.  Either way, moving the M0 to the Pi's 5v rail helped with the issue.

I then used a 4.7k pull-up resistor on the M0 reset pin and the issue has pretty much been eliminated.

Next step is to use a Y cable to split the power before it goes to the Pi and run it to the M0 as well. Taking the load off the 5v rail from the Pi.

[Felix]

Either way, moving the M0 to the Pi's 5v rail helped with the issue.
I then used a 4.7k pull-up resistor on the M0 reset pin and the issue has pretty much been eliminated.

So, power it from 5V, and add a stronger pullup (M0 already has a 10K) solved it?

[mwolter]

Yessir, also used a micro USB Y cable to split the power supply and not rely upon the Pi's GPIO 5v pin. Have not experienced the issue since.