I'm using the following Raspberry Pi :
Code: Select all
pi@pitest ~ $ sudo cat /proc/cmdline dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.board rev=0xd bcm2708.serial=0x4487f91f smsc95xx.macaddr=B8:27:EB:87:F9:1F bcm2708_fb. fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1fa00000 vc_m em.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait pi@pitest ~ $
I’ll recap the GPIO pads here a bit, because it seems to me that a few things have recently changed a bit after the latest firmware release (using the device tree kernel?).
Code: Select all
pi@pitest ~ $ uname -a Linux pitest 3.18.14+ #793 PREEMPT Sat May 30 13:15:19 BST 2015 armv6l GNU/Linux pi@pitest ~ $
The following GPIO-ports have a pull-down by default: In order of the P-1 connector: GPIO-17, 27, 22, 10 (MOSI), 9 (MISO), 11 (SCLK), 23, 24 and 25.
This pull down is regardless of an SD card present, and the pads will be pulled-low as soon as 5V is applied to the Pi.
You can easily measure this pull effect when you connect two high value resistors (significantly higher than the 50K pull resistors on the SOC- I use 1MOhm) from the GPIO pad to 3V3 and from the pad to GND. This allows you to observe the pulling high, low or none (tri-state). All the above ports show a voltage of about 140mV, suggesting to me that the pad's 50K resistor is used to create this pull-down.
When you program a pull high on any of these pads for example, this pull setting is kept during a halted mode (sudo halt), and will only switch back to the default pull low after a reboot (shortening P6) or after a software reboot (sudo reboot).
I think this is changed with the most recent firmware change because earlier, the pull seemed to be kept (in some form of EEPROM) during these states and only loose the value after a full removal of the power. This is in the BCM2835-ARM-Peripherals datasheet:
Interestingly, on my Pi now, this resetting of the pull state happens at the same time as the programming of the TXD and RXD pins, and that is 700mS into the boot sequence. The pull programming is no longer preserved over a reset or reboot, it defaults back during the boot process. If your connected hardware relied on this "feature", you better watch out.The GPIO Pull-up/down Register controls the actuation of the internal pull-up/down control line to ALL the GPIO pins. This register must be used in conjunction with the 2 GPPUDCLKn registers.
Note that it is not possible to read back the current Pull-up/down settings and so it is the users’ responsibility to ‘remember’ which pull-up/downs are active.
The reason for this is that GPIO pull-ups are maintained even in power-down mode when the core is off, when all register contents is lost.
So far so good, but there are 7 more rather special ports.
First of course the already mentioned TXD (GPIO-14) and RXD (GPIO-15). These ports are programmed to a pull-high 700mSec into the boot process, but we'll leave these two out for this discussion.
Then we have SDA0 (GPIO-2) and SCL0 (GPIO-3). As you can see on the Pi schematic, these ports are pulled high by 1K8 resistors mounted on the Pi PCB. These resistors are small in value so the pad will always read 3V3.
Now to the really interesting pads - GPCLK0 (GPIO-4), CE0 (GPIO-8) and CE1 (GPIO-7), because at first sight, they seem to behave differently.
These 3 ports are pulled high by default. They are not programmed by the SOC that way, because they are pulled high as soon as 5V is applied to the board, and even without an SD card present. I suspect again that the on-board 50K pull resistors are used, because if you use the 1M resistor measurement method above, the measured voltage is 3V0, not 3V3.
The interesting bit is that when you program the pull for these ports to low, the ports will stay that way, until we execute a halt and reset the SOC with J6. Again, after 700 mSec into the boot sequence, the pull is reset from our low setting to the default pull high again. The same happens with a sudo reboot. And again the pull goes high when also the TXD is activated, so again after 700 mSec into the boot sequence.
The screenshot below shows the TXD activity (top trace) during the boot sequence after a sudo reboot, and also the re-programming of the pull from the CE1 pad to the default high 700mSec into the boot sequence. BTW, here is a screenshot with the older kernel versions: Note the difference in the timing of the pull resetting of the CE1 pad.
So here is my question: How can the default for these 3 pads be pull-high already at power-up and without any code seemingly running (no SD card present)?
Are these 3 pads really different, or is the same method used for all the pads, also those that are pulled low by default? Common sense would dictate a yes, but what is the implication of all this?
My only explanation is that the pull settings for all pads are indeed stored in some form of EEPROM, and they will stay that way after a full powercycle.
In any case, with the latest kernel, using device trees, all pads now reset to their default state during a (re)boot and after a power cycle.
Can someone please confirm or explain this?