I'm getting some, what I would call strange, although this may be expected by those with better understanding than I have, behaviour from GPIO2.
Using Raspbian, on generic configuration, GPIO2 is set as "in":
echo "2" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio2/direction
A hardware device attached to this pin sets the pin low, which I then use to trigger a process (play a video, this may only be partially relevant), I read the pin state using:
cat /sys/class/gpio/gpio2/value
Everything works as expected, I receive the low "0" trigger, and play a video, except when the SD card is pulled from the Pi, placed in a Linux (Ubuntu) system, and an additional video file is placed into the same folder.
If this is done, once the Pi boots up again, GPIO2 never goes low again.
How this is relevant is, if I'm ssh'd into the Pi and I copy a video file to that folder, everything continues to work as expected, it is only when I manually add/replace a file on a different machine, onto the SD card, that this fails.
Just to be clear, this isn't about why the new video won't play, it does play when I manually omxplayer the file. It is just that, when a video is placed on the Pi as described above on an external machine, that GPIO2 no longer goes low. I do have another indicator for me to know that the hardware continues to attempt to set GPIO2 low.
I'm not really too concerned about what is going on, why this is happening, etc... ok, I am interested in the problem, only in the sense that I'd like to have the system recover from this undesirable condition, but I would think that resetting the GPIOs would solve this, but no matter what I do to unexport, etc. no attempt is allowing me to get the original behaviour back. The only way I can get the behaviour back to what I want, is by re-imaging the card.
Does anyone have any ideas?
Re: Strange GPIO2/pin3 behaviour?
I'm guessing the question of what board and what firmware will be asked, so:
Pi Model B rev.2
Current firmware (using rpi-update)
Pi Model B rev.2
Current firmware (using rpi-update)
Last edited by krattai on Sat Oct 04, 2014 2:10 pm, edited 1 time in total.
Re: Strange GPIO2/pin3 behaviour?
Gpios 2 and 3 (pins 3/5) are I2C SDA/SCL respectively. They have hard wired 1K8 pull-ups to 3V3. So they will normally read 1 unless driven low.
Re: Strange GPIO2/pin3 behaviour?
Hi Joan, thanks very much for the response. BTW: I plan on making extensive use of your pigpio. 
Unfortunately, I cannot comment too much on the external hardware attached to pin3 (proprietary and I don't entirely understand it, myself) I'm just the software guy on this project, but the hardware DOES drive pin3 down to low. For example, I just re-imaged the Pi and the device just drove pin3 down and triggered video play.
When I reboot the Pi using sudo reboot, the everything continues to work as expected, but I also just confirmed that when the Pi is powered down and then powered back up, the Pi behaviour changes to the undesired behaviour where pin3 is not being driven down.
On the bench test unit / image the hardware guy uses, this is not the case. Powering down / powering up, etc. does not change the behaviour and everything keeps working as expected.
Unfortunately, I cannot comment too much on the external hardware attached to pin3 (proprietary and I don't entirely understand it, myself) I'm just the software guy on this project, but the hardware DOES drive pin3 down to low. For example, I just re-imaged the Pi and the device just drove pin3 down and triggered video play.
When I reboot the Pi using sudo reboot, the everything continues to work as expected, but I also just confirmed that when the Pi is powered down and then powered back up, the Pi behaviour changes to the undesired behaviour where pin3 is not being driven down.
On the bench test unit / image the hardware guy uses, this is not the case. Powering down / powering up, etc. does not change the behaviour and everything keeps working as expected.
Re: Strange GPIO2/pin3 behaviour?
*sigh*
Oh, no they didn't...
OK, I checked firmware versions. The device that the hardware guys uses is:
Jan 6 2014 21:19:57
Copyright (c) 2012 Broadcom
version b00bb3ae73bd2799df0e938b7a5f17f45303fb53 (clean) (release)
The systems that are "broken":
Oct 1 2014 22:40:40
Copyright (c) 2012 Broadcom
version 93c98148caed4bc6e4a741944c2717318874e387 (clean) (release)
I was building and testing on the firmware just prior to the Oct. 1/2014 release and everything (from what I remember) was working fine...
Oh, no they didn't...
OK, I checked firmware versions. The device that the hardware guys uses is:
Jan 6 2014 21:19:57
Copyright (c) 2012 Broadcom
version b00bb3ae73bd2799df0e938b7a5f17f45303fb53 (clean) (release)
The systems that are "broken":
Oct 1 2014 22:40:40
Copyright (c) 2012 Broadcom
version 93c98148caed4bc6e4a741944c2717318874e387 (clean) (release)
I was building and testing on the firmware just prior to the Oct. 1/2014 release and everything (from what I remember) was working fine...
Re: Strange GPIO2/pin3 behaviour?
OK, I went over to the raspberrypi/firmware github, posted an issue and worked with popcornmix to get a resolution on this:
https://github.com/raspberrypi/firmware/issues/321
It was discovered that a post July 5th, 2014 gpioman firmware update created this new behaviour of GPIO2 which subsequently caused me to get this undesirable behaviour.
Using the July 5th, 2014 firmware has resolved the issue.
That wouldn't mean that the current firmware is broken or wrong, just that the expected behaviour that I need in the current external hardware / pi matchup is no longer working. I may ask the hardware guy to change pinouts to solve for future.
https://github.com/raspberrypi/firmware/issues/321
It was discovered that a post July 5th, 2014 gpioman firmware update created this new behaviour of GPIO2 which subsequently caused me to get this undesirable behaviour.
Using the July 5th, 2014 firmware has resolved the issue.
That wouldn't mean that the current firmware is broken or wrong, just that the expected behaviour that I need in the current external hardware / pi matchup is no longer working. I may ask the hardware guy to change pinouts to solve for future.
Re: Strange GPIO2/pin3 behaviour?
I don't understand what is meant to have happened here.
Gpios 2/3 have hard wired pull-ups. The hard pull-up are much stronger than the internal pull-ups which will have no affect on gpios 2/3.
What has actually changed? Are they now set as inputs rather than outputs?
Gpios 2/3 have hard wired pull-ups. The hard pull-up are much stronger than the internal pull-ups which will have no affect on gpios 2/3.
What has actually changed? Are they now set as inputs rather than outputs?
Re: Strange GPIO2/pin3 behaviour?
The hardware guy set up GPIO2 as input, he was working with firmware prior to July 15, 2014. Based on his design, the model B rev2, and the firmware at the time of his design, it (signalling on GPIO2) worked.
So while I don't know why it DID work, on boot GPIO2 was high (I do not know how pin3 begins as 1, all I know is it is when the software starts running), then his hardware would pull GPIO2 low (0), and reading GPIO2 change to low, the software triggered properly. Basically, the external hardware drops the pin low only for a duration at which it is getting a signal, at which point it pulls pin high, again. Basically, I need to do realtime detection with microsecond response.
Anyhow, with the July 15, 2014 firmware addition of gpioman, his hardware indicates (by way of LED) of the pull low pulse, but GPIO2 (of course still set as "in" direction) no longer drops to low, so the software does not read the pulse and therefore does not trigger as desired.
So while I don't know why it DID work, on boot GPIO2 was high (I do not know how pin3 begins as 1, all I know is it is when the software starts running), then his hardware would pull GPIO2 low (0), and reading GPIO2 change to low, the software triggered properly. Basically, the external hardware drops the pin low only for a duration at which it is getting a signal, at which point it pulls pin high, again. Basically, I need to do realtime detection with microsecond response.
Anyhow, with the July 15, 2014 firmware addition of gpioman, his hardware indicates (by way of LED) of the pull low pulse, but GPIO2 (of course still set as "in" direction) no longer drops to low, so the software does not read the pulse and therefore does not trigger as desired.
Re: Strange GPIO2/pin3 behaviour?
None of your conclusions are very credible.
The only firmware change is whether or not it leaves the weak (~50kΩ) on-chip pull up enabled at boot. The pin in question has a strong (1.8kΩ or 1.6kΩ) pull up resistor on the board, so the 50kΩ in parallel only makes a 3% difference.
In the unlikely event that the 3% difference is enough to break your application, you should be able to prove that by enabling and disabling the weak pull yourself. If so, your design is too fragile and you must either increase the drive strength of the input signal or connect it to a non-I²C pin (GPIO4 or above), which does not have a physical pull up resistor.
Even if you do care about weak on-chip pulls, you do not necessarily need to mess with the firmware or device tree. That only sets the initial state at boot. You can enable and disable pulls yourself later on. Admittedly the kernel /sys/class/gpio interface does not provide a method for this, but most other GPIO libraries do.
If you want to detect pulses that last only microseconds then you must enable falling edge hardware interrupts and use a GPIO library that can respond to those events. Just "cat value" is going to miss the pulse.
The only firmware change is whether or not it leaves the weak (~50kΩ) on-chip pull up enabled at boot. The pin in question has a strong (1.8kΩ or 1.6kΩ) pull up resistor on the board, so the 50kΩ in parallel only makes a 3% difference.
In the unlikely event that the 3% difference is enough to break your application, you should be able to prove that by enabling and disabling the weak pull yourself. If so, your design is too fragile and you must either increase the drive strength of the input signal or connect it to a non-I²C pin (GPIO4 or above), which does not have a physical pull up resistor.
Even if you do care about weak on-chip pulls, you do not necessarily need to mess with the firmware or device tree. That only sets the initial state at boot. You can enable and disable pulls yourself later on. Admittedly the kernel /sys/class/gpio interface does not provide a method for this, but most other GPIO libraries do.
If you want to detect pulses that last only microseconds then you must enable falling edge hardware interrupts and use a GPIO library that can respond to those events. Just "cat value" is going to miss the pulse.
Re: Strange GPIO2/pin3 behaviour?
lol, my life as a geek is filled with examples of things that I've done successfully, that were preceded by other's statements of can't and shouldn't... 
This is an upgrade of an older device that we've been using for the past 8 years (that I was commissioned to create as an upgrade of the DVD player abomination they were using lol):
http://ihdn.ca/Xpo_VI.html
And that hardware has been married to my open source AEBL device, which we did about a year ago:
https://github.com/krattai/AEBL
The solution here is really quite simple, I tell the hardware guy to stop using pin 3 for all future production units and we hold the firmware at Jul 5, 2014 for those that are already in the field.
The only thing I have been looking for is a different work around which was more of a fix than a cludge. B)
This is an upgrade of an older device that we've been using for the past 8 years (that I was commissioned to create as an upgrade of the DVD player abomination they were using lol):
http://ihdn.ca/Xpo_VI.html
And that hardware has been married to my open source AEBL device, which we did about a year ago:
https://github.com/krattai/AEBL
The solution here is really quite simple, I tell the hardware guy to stop using pin 3 for all future production units and we hold the firmware at Jul 5, 2014 for those that are already in the field.
The only thing I have been looking for is a different work around which was more of a fix than a cludge. B)