Default pin pull state upon boot

[industrial-pi]

Hello,

I am evaluating the use a Raspberry Pi Model B+ v1.2 board in an industrial control system. I am perfectly able to control all the pin pullups and pulldowns from userspace (I have verified all with an oscilloscope) however this does not help me.

In particular, I need to disable the pullup on GPIO17 which is connected to a hardware watchdog circuit in my application. The pin must float, with no more than 10 uA leakage current, until it first drives the watchdog. The 50-60 kOhm internal pullup is enough to drive more than 3 times the allowed leakage current.

After driving the pin with more than 10 uA for the first time, the Pi must contine toggling it faster than 10 Hz to prevent the watchdog circuit from triggering an alarm, leaving no time to boot and start a toggling process from userspace.

The board runs raspbian and raspberrypi-bootloader version 1.20150923-1 straight out of the repository.

I have unsuccesfully tried changing the default pullup resistor state of GPIO17 by following the dt-blob method described at the following link.

https://www.raspberrypi.org/documentati ... uration.md

Could you please let me know if the article above is still current and if there is any diagnostic messaging that can be enabled to allow troubleshooting this.

Some more information: I read in the BCM2835 ARM peripherals datasheet (page 100, GPIO Pull-up/down register GPPUD) that "the pullups are maintained even in power-down mode when the core is off, when all register content is lost". And if I disable the pullup from userland, and issue a sudo reboot command, the pull stays in the last state (as expected) until the next cold boot.

Another piece of information is that I am unable to change the deafult pull state to down as well as off. In other words, after a cold boot the pull is always up.

I really like the raspberry and it's a perfect fit for our application, however I'll have to drop it unless I can disable the pull upon boot.

[dom]

If you don't get a response from someone who has successfully done this then create a github issue here:
https://github.com/raspberrypi/firmware/issues

where more of the devs will see it. Include your mods to dt-blob.
I think what you want is theoretically possible, but may need a bit of digging to work out where the GPIO pulling state gets reset (e.g. bootcode.bin, start.elf or kernel) and if that can be avoided.

[industrial-pi]

If you don't get a response from someone who has successfully done this then create a github issue here:
https://github.com/raspberrypi/firmware/issues

where more of the devs will see it. Include your mods to dt-blob.
I think what you want is theoretically possible, but may need a bit of digging to work out where the GPIO pulling state gets reset (e.g. bootcode.bin, start.elf or kernel) and if that can be avoided.

Ok thanks for the fast reply. I'll give it some time then post the issue on github. I am certain that the kernel is not touching the pull state, and it must be the bootloader setting it high during cold boot.

[PhilE]

GPIO 17 should pull down by default. I've just verified that my B+, with no dt-blob.dts, boots up with a pull down; with a scope configured with a rising edge trigger at 500mV I've been through a full reboot cycle and it doesn't trigger.

Can you post the output of "uname -a", "cat /boot/.firmware_revision" and "sudo vcdbg log msg"?

[jojopi]

In other words, after a cold boot the pull is always up.

On a cold start, the pull state of GPIO17 is actually down, as given in Table 6-31 on Page 102.

This is the hardware's power-on state, and it applies even with no SD card inserted. At best the firmware can disable the pull some fraction of a second later.

The datasheet line about "maintained even in power-down mode when the core is off" has confused a lot of people. It means that the pull states are statically latched, not that they are held in non-volatile storage.

Have you considered buffering or gating the signal, so that it is only sensitive to being driven, and not to weak pulling?

[PhilE]

It's probably also worth deleting/renaming any dt-blob.dts you have, disconnecting GPIO17 and rebooting. Although it isn't possible to read back the pull state, you can use "[sudo] raspi-gpio get 17" to show the current input level, which should be 0. You can then verify that the pulls and level detection are working as expected by enabling the pull-up on the pin ("[sudo] raspi-gpio set 17 ip pu") and re-reading the input, which should now be a 1. You can also distinguish no-pull from a pull using a high-valued resistor (e.g. 1MOhm) to pull the pin high, then low, verifying each time that the detected input value tracks the external pull-up.

You can get raspi-gpio, if you don't already have it, using "sudo apt-get install raspi-gpio".

[joan]

You can not rely on the GPIO being high or low or floating until your software/hardware controls the GPIO. Even then some other software/hardware may override your setting.

I suspect the best you can do is use hardware to set a strong pull in the direction you want.

[industrial-pi]

Archive.zip

(5.01 KiB) Downloaded 32 times

It's probably also worth deleting/renaming any dt-blob.dts you have, disconnecting GPIO17 and rebooting. Although it isn't possible to read back the pull state, you can use "[sudo] raspi-gpio get 17" to show the current input level, which should be 0. You can then verify that the pulls and level detection are working as expected by enabling the pull-up on the pin ("[sudo] raspi-gpio set 17 ip pu") and re-reading the input, which should now be a 1. You can also distinguish no-pull from a pull using a high-valued resistor (e.g. 1MOhm) to pull the pin high, then low, verifying each time that the detected input value tracks the external pull-up.

You can get raspi-gpio, if you don't already have it, using "sudo apt-get install raspi-gpio".

I've got an oscilloscope so I can monitor the pin level, no need to read back anything. I tried of course with various resistors. The default pull is UP, even if I boot without an SD-card.

I can change the pin pull as I want from userspace and it survives a warm boot, initiated by either shorting the RUN pin to ground or a sudo shutdown. But on cold boot it turns back on, regardless of what I do in dt-blob.

uname: Linux raspberrypi 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux

There is no .firmware_version but I vcgencmd version says
Sep 23 2015 12:12:01
Copyright (c) 2012 Broadcom
version c156d00b148c30a3ba28ec376c9c01e95a77d6d5 (clean) (release)

I also attach the output of vcdbg, dt-blob.dts and dt-blob.bin

[joan]

GPIO 17 is ce1 (pin 11). Perhaps a SPI module is being loaded which is defaulting the chip select 1 (ce1) to high for the auxiliary SPI (as it should).

[PhilE]

Interesting thought, but I doubt it. That should be detectable, since the pin function can be read back.

I can confirm that using the attached dt-blob.bin I get no pull, and without it (after a power-cycle) I still get a pull down.

Although I understand that you may be forced to use GPIO 17 for your design, have you looked at the power-up states of any other pins? GPIOs 0-8 pull high by default, and the others pull down. The dt-blob.bin overrides the defaults for 14 and 17, setting them to no_pulling.

Can you confirm that your testing is being done with no hardware attached to the header pins?

[jdb]

How about using a tri-state buffer between the GPIO and your watchdog?

On boot, you have low-value resistor pulls on the #OE and IN pins of the tri-state buffer so the output floats, then as soon as the software comes up you assert #OE and start toggling IN.

e.g. https://www.fairchildsemi.com/datasheet ... 7sz125.pdf

[industrial-pi]

How about using a tri-state buffer between the GPIO and your watchdog?

On boot, you have low-value resistor pulls on the #OE and IN pins of the tri-state buffer so the output floats, then as soon as the software comes up you assert #OE and start toggling IN.

e.g. https://www.fairchildsemi.com/datasheet ... 7sz125.pdf

I can't change the hardware but with a pin inversion (using GPIO4) it works. I would think this is a hardware failure of GPIO17 but if that were the case I should not be able to change it from userspace.

[joan]

...
I can't change the hardware but with a pin inversion (using GPIO4) it works. I would think this is a hardware failure of GPIO17 but if that were the case I should not be able to change it from userspace.

You have gone from a GPIO defaulting to pull-down to a GPIO defaulting to pull-up.

Isn't it more likely that this is a fault in the attached system?