Forums » Software Development »
GPIO Output immediately after power on
Added by Christian Rückl almost 11 years ago
Hi,
Does anybody know where it comes from, that i get immediately a signal on some pins after the module is powered on???
This happens before the Linux kernel will loaded! Has this something to do with the configuration of u-Boot-Bootloader?
If the answer is yes, can somebody tell me what would be the easiest way to have from the moment of powering on until the kernel is loaded only the UART, EMIF and SPI available and not other signals already turned on?
I hope the interfaces above are all what needs to be enabled for starting up Linux!?
Thanks for your help!
Christian
Christian,
there are 2 possibilities for where pins are being enabled and potentially toggled. A lot of this depends on which pins you are talking about too.
The processor has a pre-defined reset state for every pin, which is listed in the datasheet. Off the top of my head, I'm going to say anything that
is a potential GPIO would be tristated, but you should really check the datasheet. Also, when the processor boots, it will toggle certain pins depending
on the boot mode selected. The MityDSP-L138 boots from SPI1 flash though, so I don't think the ROM bootloader would be toggling any pins except for the
SPI interface. U-boot does do some pin configuration and uses the EMIF, I2C, SPI, and UART. The source for u-boot is available on our git repository
(see the u-boot section of the wiki for details) . Certainly, once linux is up and drivers are loaded, a lot more is going to happen.
An important piece of information to have here would be exactly which pin(s) are we talking about.
cheers
/Tim
Tim,
thanks for the fast reply!
The following Pins on the L138 (no FPGA-Version)SoM are driven at the beginning of the startup sequence, also when i'm only in the u-boot terminal.
- 14
- 32
- 36
- 44
- 118
- 128
- 134
- 162
- 164
- 176
- 178
- 182
- 194
These are the pins what I can see by now. Maybe there will be more driven Pins...
I tried also to find out the reset state of the pins but until know i couldn't found anything 
where is it written? in the TRM?
thanks
Christian
Keep in mind that the OMAP-L138 also has built in pull-up and pull-down resistors on just about every pin.
On reset, IIRC, most of the pins have weak pull-ups enabled. Search for the PUPEN register in the TRM and check the state. Unfortuneately the pull-ups are enabled in groups at a time (1 32 bit register, 144+ pins...).
The default state of the pins should be in the OMAP-L138 datasheet. The default pull-up/pull-down/disabled state is based on the default PUPEN registers, documented in the TRM.
-Mike
Ohh, OK.
I found a way at Ti's support page how to change the UBL to set the defaultstate of the PUPDSEL-registers:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/185405.aspx?pi21918=1
but this change will happen after ~160ms after POR. This can cause some problems in my system, mostly for the pulled up pins, there are controllines connected to them and they are active high....
Is there any other possibility known to have this pins always low at POR??
christian
The only way I know of is to use stronger pull downs (1 or 2K I think) externally. You'll burn a bit more power and have to cobb up your board if it's already implemented....
We've been burned by those pull-ups quite often, particularly with PHY's that strap their address and control mode through RxD pins connected to the OMAP-L138 MII pins....
-Mike
Thanks Mike,
the stronger pull downs should be acceptable in my design.
christian
Go to top
