PYNQ: PYTHON PRODUCTIVITY

False detected gpio input

Support
#1

I have setup one gpio as output and one as input.
For testing purposes, I just hardwired the output to the input and executed my IP which generates outputs on the output pin while also reading the input pin.

After seeing some weird behaviour, such as detecting input when no output was generated, I started googling and saw this which sadly doesn’t have a solution.

Basically, even when the output is not connected to input and only a loose cable of ~15cm is connected to the input, an input signal is falsely detected. If I remove the cable, no input signal is detected.

How should one go about?

#2

It would help if you could post more details about your design to check if there are any issues with it, or describe your issue in more detail.
Could your wire be picking up some RF noise or do you have any potential sources nearby? Perhaps try a different wire length?

Cathal

#3

I’ve tried cables from ~15cm - 1.5m with same results.

When connecting as in

  1. I detect the expected outputs and occasionally unexpected inputs
  2. I occasionally detect unexpected inputs
  3. I don’t detect any inputs.

Should it be connected as in 4.?

false_gpio
false_gpio928×597 3.71 KB

#4

What IP are you using to control both your input and outputs?
Are the signals switchgn at high speeds and could you just be detecting the wrong value that you expect, or do you see the signal switching randomly when it should be stable?

For 4, you could connect the input directly to ground. (E.g. if you are using the Pmod, there is a ground pin)

Cathal

#5

I’m using my own IP and contraints

io_port
io_port1202×255 18.7 KB 

##IO inputs
set_property -dict { PACKAGE_PIN U13   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[0] }]; #IO_L3P_T0_DQS_PUDC_B_34 Sch=ck_io[2]
set_property -dict { PACKAGE_PIN V13   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[1] }]; #IO_L3N_T0_DQS_34 Sch=ck_io[3]
set_property -dict { PACKAGE_PIN V15   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[2] }]; #IO_L10P_T1_34 Sch=ck_io[4]
set_property -dict { PACKAGE_PIN T15   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[3] }]; #IO_L5N_T0_34 Sch=ck_io[5]
set_property -dict { PACKAGE_PIN R16   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[4] }]; #IO_L19P_T3_34 Sch=ck_io[6]
set_property -dict { PACKAGE_PIN U17   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[5] }]; #IO_L9N_T1_DQS_34 Sch=ck_io[7]
set_property -dict { PACKAGE_PIN V17   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[6] }]; #IO_L21P_T3_DQS_34 Sch=ck_io[8]
set_property -dict { PACKAGE_PIN V18   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[7] }]; #IO_L21N_T3_DQS_34 Sch=ck_io[9]
set_property -dict { PACKAGE_PIN T16   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[8] }]; #IO_L9P_T1_DQS_34 Sch=ck_io[10]
set_property -dict { PACKAGE_PIN R17   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[9] }]; #IO_L19N_T3_VREF_34 Sch=ck_io[11]
set_property -dict { PACKAGE_PIN P18   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[10] }]; #IO_L23N_T3_34 Sch=ck_io[12]
set_property -dict { PACKAGE_PIN N17   IOSTANDARD LVCMOS33 } [get_ports { IO_PORT_I[11] }]; #IO_L23P_T3_34 Sch=ck_io[13]

There is a slight difference in false detection when changing speed.

“could you just be detecting the wrong value that you expect,”, I would guess not, since 2. and 3.

I’m not using pmod, I’m using the the DIO’s (used for the shield connector, but have not plugged in the shield connector).

Are you saying merging 4 and 1 should maybe do the trick… with R=0.?

Edit: I was advised to put a 10kOhm resistor at R.

#6

I’d check your IP and code if you detect incorrect values with (1).
It doesn’t matter if you are using Pmod or the Arduino/RPi pins. There are ground pins available on all those interfaces, and you can use any of them.
Why were you advised to add a resistor? It shouldn’t matter if you are doing some quick tests. You are just connecting GND/“logic 0”. I’m assuming you don’t want to leave an input permanently connected to ground in your real system.

Cathal

#7

aha… NOW I get why you said connect the input to GND… to check for the “unexpected” detections. But as mentioned previously, doesn’t this theory get killed by the two cases 2 and 3?

The advise of putting a resistor between input and gnd was to create a sort of a pull-down, so that noise doesn’t get detected.

Yes, my IP might need a thorough review, since it is using axi streams (I have another IP which doesn’t use streams and is a one shot loop). I don’t detect unexptected bits there. Still… I still can’t get my head around 2 and 3 in the stream case…

#8

For 2 and 3 your input is floating (neither ‘1’ or ‘0’) and non-deterministic, so it could be detected as either depending on the internal circuitry of the board. With 2, you are also creating an antenna by connecting a wire, so you may pick up more noise in this scenario.

If you have 1, as long as you are driving your output high or low you should only see a 1 or 0 on your input. For 4, you should only ever see a 0 on your input.

Cathal