Author Topic: FPGA button input triggering when touching one end of a wire? (re: A/C noise?)  (Read 835 times)

0 Members and 1 Guest are viewing this topic.

Offline sofakngTopic starter

  • Regular Contributor
  • *
  • Posts: 79
  • Country: us
I'm trying to troubleshoot a problem with my DE10-Nano FPGA kit.  (using the MiSTer firmware/application)

GPIO17 is configured as a reset button input. 

If I touch a screwdriver (or one end of disconnected wire) to this pin then it activates as if the button was pressed. 

If I connect a push-button switch between GPIO17 and GND then it will activate the input even when the button is not pressed but no continuity exists between GPIO17 and GND.

If I try to measure continuity while the FPGA is turned on then it will activate the reset.


I'm not sure if the FPGA is configured with an internal pull-up resistor on that pin so I added a 10k (and tried 4.7k) pull-up resistor.  It worked when I had the FPGA on my desk but when I put it into my arcade cabinet it kept activating with just disconnected wires attached.

Could there be a problem with high-frequency (?) noise possibly coming from the arcade CRT TV or other sources?

If so, how can I start troubleshooting or fix the problem?

I have an oscilloscope (Rigol DS1054Z) but I'm still really learning the basics of electronics.  I think I can enable A/C coupling and see if any A/C noise exists on the line but I'm not quite sure what I'm doing or what to do to solve even if that's the problem.

Thanks for any advice!
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: au
If it activates when touched with disconnected wire, it suggests the input is not-biased and undefined. The manual https://www.mouser.com/datasheet/2/598/DE0_Nano_User_Manual-876807.pdf, fig 3.2 shows hardware debouncing of reset using external pull-ups, albeit it is not gpio.

So the intuition to add 10k pull-up seems right to me. 

Try to get the source code for the firmware and see how the pin is defined (in/out/pu/pd/od) after initialization.

When moved to the cabinet - do you also put it on a different power-supply? Is there adequate decoupling?

Is the gpio pin 17 configured to do a soft-reset - or a hard-reset somehow? hard reset would be odd, given there's already a hard-reset pin, and it would interfere with fpga intialization. 
 
 

Offline sofakngTopic starter

  • Regular Contributor
  • *
  • Posts: 79
  • Country: us
Thanks so much for the response and information.

I'm not familiar with FPGA code but somebody said they verified the code and that it was using an internal pull-up resistor:

Code: [Select]
set_location_assignment PIN_AG23 -to BTN_RESET
set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to BTN_*
set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to BTN_*

I'm still learning but I took a look on my oscilloscope.  When I touch a screwdriver or tweezers to GPIO17, the voltage drops to 1.68v:



Also, the board has physical buttons in addition to the pin headers (for the same GPIO pins).  If I press the button next to GPIO17 (ie. GPIO13 or GPIO15), then GPIO17 -ALSO- drops in voltage:



Does this provide any clues?
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: au
Quote
If I press the button next to GPIO17 (ie. GPIO13 or GPIO15), then GPIO17 -ALSO- drops in voltage:

Do you have another board, that could be quickly substituted?

Is the configuration for GPIO with internal pull-ups on other GPIO pins working as expected? 

In the source - is there maybe some alternate function configuration that has been enabled that disables GPIO functionarity, or peripheral clock routing etc - that might mean the GPIO is not working as expected. Obviously, I am guessing but that is where I would look.
 

Offline sofakngTopic starter

  • Regular Contributor
  • *
  • Posts: 79
  • Country: us
I have two boards that function the exact same way, and I also had a third person verify the same with his board.  :(
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 740
  • Country: au
If the input mosfet gates are undefined, then I can *imagine* stray leakage from another pin draining the gate capacitance to turn a pin off. That is why I would look at the source code, for some misconfiguration. The posted source indicates that gpio is in and pulled high, but it is not behaving that way.  If you could synthesize and deploy a bitstream to just blink blink a led on input, it would help verify.
 

Offline sofakngTopic starter

  • Regular Contributor
  • *
  • Posts: 79
  • Country: us
This project is using the MiSTer software for the DE10-Nano.

I've reached out to the authors but haven't received a response and don't know enough about the code to check for any errors.  (EDIT: I've just submitted an issue on github as well.)

Is there anything I can do in the meantime to fix/workaround the issue?  (ie. adding pull-up resistor/capacitor, etc)

Adding a 0.1uf capacitor between GPIO17 and GND seemed to fix the problem, but I didn't test it long enough nor do I know if this is the correct solution.  (aside from double-checking the code is correctly pulling up the pin)
« Last Edit: August 23, 2020, 03:24:38 am by sofakng »
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 3490
  • Country: ua
I think it's better to use some buffer IC if you're want to connect long wires to FPGA, because FPGA pins are very sensitive and it can be easily damaged. They don't intended to use with a long wires.
 

Offline sofakngTopic starter

  • Regular Contributor
  • *
  • Posts: 79
  • Country: us
Thanks for the reply.  Do you have any suggestions?

I'm using the DE10-Nano FPGA kit with a MiSTer I/O board on top.  It connects to the GPIO pins and exposes them via a JST-XH header.

When I was researching button debounce I read about Schmitt Triggers (74HC14).  I could connect a 74HC14 to the JST-XH pins and then connect the buttons to that instead?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf