MityARM-335x LED D3 GPIO Pin?

Added by Joel Minski about 11 years ago

Section 3.7 of the "MityARM-335x Carrier Board Design Guide.doc" from January 8, 2012 states that LED D3 is connected to a GPIO pin and can be software controlled.

Which AM3359 GPIO pin is connected to this LED? How should the PINMUX settings for this GPIO pin be configured?


Replies (3)

RE: MityARM-335x LED D3 GPIO Pin? - Added by Michael Williamson about 11 years ago

On the AM335x, D2 and D3 are connected to the TPS65910. D2 is connected to VDIG1 (VDIG1 output is only used for D2, no other circuits are powered by VDIG1). Typically, D2 is used as a "Powered" indicator for the module.

D3 is connected to GPIO_CKSYNC on the TPS65910. The CL modified u-Boot toggles this I/O during low level boot to provide an indication that it was loaded and then jumped to the main application / kernel. To toggle D3, you need to send an I2C command to the PMIC to toggle the I/O. I don't know this command off-hand, we'll follow this post up the the appropriate code (or you can check the spec sheet on the PMIC if you like). The i2cset command line utility should work to flip the bit.

Note: both of the diodes returns are connected to the LED_RTN pin on the edge connector (pin 30). You need to ground this pin to get the LED's to work. This was done to allow applications to disable the LED's (particularly, the power indication of D2) to reduce power consumption.

Hope this helps.


RE: MityARM-335x LED D3 GPIO Pin? - Added by Joel Minski about 11 years ago

Hi Mike,

Thanks for the help on where to look. I found the set_led_d3() function inside som.c in u-boot where this is being done.

I was curious why D3 was not turning on when using our new carrier board and whether we were reusing a GPIO it needed.

It seems the reason the LED isn't turning on is actually that we aren't able to talk to the TPS65910 PMIC over I2C1. I've posted more information here:

RE: MityARM-335x LED D3 GPIO Pin? - Added by Tim Iskander about 11 years ago

The reason you can't talk to the PMIC (from linux) is likely that the pmic driver has grabbed the bus for itself.
If you are using the cmd line tools, you can add the -f flag to force it (I believe)
I'm pretty sure there is a way to override the busy aspect
"You can override the current "owner" by using I2C_SLAVE_FORCE instead of I2C_SLAVE. Depending on the implementation the previous owner may still try to control the I2C device but you will be at least able to read values back."
as in

ioctl(fd, I2C_SLAVE_FORCE, 0x2D);

hope this helps

    Go to top
    Add picture from clipboard (Maximum size: 1 GB)