On my cape I use PIN9.15 (GPIO1_16) to control an ON/OFF process through a NPN transistor. This cape worked just right on white BB. Now I´m trying the cape on a new BBB I noted that the power on process is started just when the BBB is powered up and I need to start the process after a few conditions are met.
I noted that on my white Beaglebone once power is up and uBoot starts this PIN stay low just as expected (isn´t in SYSBOOT) but on the BBB it starts at 1.0 - 1.6V which starts my process earlier than it should.
I played in uBoot with “gpio clear 48” which do sets the pin low but then the Kernel starts and it switch to 1.6V again and I´m setting pin muxing through a DTBO which describes my cape. But the level goes low just after I use “echo out > /sys/class/gpio/gpio48/direction” on Linux. Even I forced the muxing of this pin to GPIO1_16 on uBoot and recompile but somewhere is changed back to 1.6V on uBoot and in the Kernel afterward.
PIN9.15 is GPIO1_16, gmpc_a0, gmii_ and rmii_ something which AFAIK isn’t used for anything on the new BBB it isn’t a SYSBOOT pin so I can’t figure why this pin is starting at 1.6V and even changing it to 0V using uEnv.txt after Kernel boot it goes to 1.6V again.
I managed to set the pin on early init on uBoot and it does work. But afterward when Kernel is booting it changes the pin back and keep that way until I set out direction on the GPIO using Linux gpio interface.
The 3.8 does not affect what is needed to control the pins, That is all protected by hardware in the chip. The 3.8 kernel does affect how pins are controlled with things like overlays. I suggest you read the document located at https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub . It should answer some of your questions.
I must add that on my white BeagleBone I’m running the exact same kernel that on the BBB which is 3.8.13-bone20. I was on understanding that the DTS are applied the same on the BBW and BBB for 3.8.
It seems that for 3.8.13 on the BBB the DTS that are loaded before any overlay change PIN9.15 mux or just reset it to mode 0. But I cannot find any mention to gpmc_a0 on those DTS/DTSI
Indeed PIN9.15 on BBB is a bit different than old BB. Seeing schematics one can see that T13 (GPIO2_0) is also connected on PIN9.15, on the original BB only R13 (GPIO1_16) was connected to pin 9.15.
So now GPIO1_16 and also GPIO2_0 is connected to PIN9.15. Sadly T13 (GPIO2_0) seems to start as GPMC or MMC2 or something that gets you 1.0-1.6V on this pin on start which could lead to problems on power up on some capes.
By now I just desoldered R161 (which connects T13 to PIN9.15) but I´ll change my design to use another pin which do start at 0V on powerup.
Yes it is. I added the ability to bring out the MMC2 CMD line. Unsoldering the resistor is what they are there for. No sadness needed. Sadness only in the SW was unable to control the HW correctly.
So. Can I suppose that since MMC2 can be used for booting the AM335X is starting with MUXMODE on MMC_CMD2 ?
Maybe there is someway to avoid current behavior on Linux. On uBoot one can issue a gpio_request and gpio_output early on boot fast enough (about 700ms) after powerup which don´t trip my specific circuit (it may trip other capes). Problem is that when Linux boot, the levels get messed up again; maybe MMC software tries to drive the pin.
So, Gerald,
Why do you think it is an acceptable condition to to have GPIO1_16 fighting GPIO2_0 on boot up, and perhaps forever for the case that a BBB user doesn’t happen to notice this condition, which violates the AM3358 recommended operating conditions? Ref: TI SPRS717J –OCTOBER 2011–REVISED APRIL 2016 page 92, VOH and VOL, normal operation characteristics.
John C.
Something in U-Boot v2016.03 is tickling this problem.
John C and I are working on a product that drives an LED from GPIO1_16. With the stock BBB bootloader (2015.01), it stays off (0V) on boot, as expected. But we ran into occasional phantom keypresses halting the boot, so I made a custom build from the latest U-Boot sources (v2016.03). That’s when we noticed our LED turning on dim (1.6V).
I iterated through every U-Boot release tag from v2015.04 to v2016.03 and found that the problem only exists in v2016.03. v2016.01 and earlier are fine. Who can explain the change in behavior?
You can just do a git diff between the two releases. Search google on how to do this. There are probably a lot of changes, but concentrate on just the areas that would affect the issues you are concerned about.
and keep that way until I set out direction on the GPIO using Linux gpio interface.