Any difference for PIN9.15 (GPIO1_16) on new BBB

[Juanjo]

Guys,

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.

Any help would be appreciated.

Thanks

[Gerald Coley]

I suspect that nothing is being done with the pin. As opposed to the BeagleBone where the pins were setup on boot.

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Gerald

 

ger...@beagleboard.org

g-co...@ti.com

http://beagleboard.org/

http://circuitco.com/support/

[Juanjo]

Thanks Gerald,

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.

I wonder if the pin mux kernel parameters defined on http://processors.wiki.ti.com/index.php/AM335x_PSP_User's_Guide still applies to 3.8.X

[Gerald Coley]

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.

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Juanjo]

Thanks Gerald !

[Juanjo]

BTW,

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 :(

[Juanjo]

Update,

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.

[Gerald Coley]

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.

Gerald

[Juanjo]

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.

[Gerald Coley]

I don't know if MMC2 can be used or not. I don't think it can. I know it is not in the boot path for sure.

To stop tripping your circuit, I would look at adding a capacitor.

Gerald

[jcar...@thingmagic.com]

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.

[Gerald Coley]

They come up as inputs.

Gerald

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/fab7b4cc-8974-47d4-ba1b-f4861e2143ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Gerald

 

ger...@beagleboard.org

http://beagleboard.org/

gco...@emprodesign.com

[ht...@thingmagic.com]

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?

Harry T.

[John Syne]

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.

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/28fb0c4f-c97c-4f5a-8564-ecd02fde338a%40googlegroups.com.