This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
PPC852T port pin configuration questions
- From: Steve Strublic <SStrublic at Hypercom dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Thu, 16 Sep 2004 15:59:22 -0700
- Subject: [ECOS] PPC852T port pin configuration questions
Hi,
I was investigating an issue with our product, that is using eCos and the PowerPC 852T. I traced it
down to a specific area of code that configures ports A, B, and C.
The specific code is in hal/powerpc/mpx8xx/.../src/var_misc.c, and is specific to the 852T.
#if defined(CYGHWR_HAL_POWERPC_MPC8XX_852T) && !defined(CYG_HAL_STARTUP_RAM)
// Only do this if we are not a RAM startup, otherwise we risk
// disturbing settings made by RedBoot.
// Special settings - according to manual errata
eppc->pio_papar &= ~0xffffffff; // PA manatory settings
eppc->pio_padir |= 0xffffffff;
eppc->pip_pbpar &= ~0x0003ff07; // PB29..31 AS GPIO
eppc->pip_pbdir |= 0x0003ff07;
eppc->pip_pbdat = 0x00010007;
eppc->pio_pcpar &= ~0xffffffff; // PC manatory settings
eppc->pio_pcdir |= 0xffffffff;
#endif
Our specific issue is that these are interrupt-capable inputs in our product, and the hardware pulls
the pins to that state. Forcing the pins as outputs without completely configuring the PCSO
register causes the pins to reach a state that is neither zero or one.
I looked through the errata for the 866/852T and I don't see the need to perform this operation. I
saw no specific errata that stated the values of ports A/B/C/D were unknown at startup.
In fact, the configuration of port C as all outputs is a specific danger, as they default to inputs
at powerup. Driving them as outputs may prevent them from being configured as spurious interrupt
sources, but in truth the PPC defaults them as general-purpose inputs with no interrupt capability.
And I don't understand the desire to force ports A and B to their configurations above... I could
not locate any references in any errata or manual.
Also, not everyone uses Redboot to boot their product... we aren't. This causes a difficulty when
powering up a RAM-based image that does not use Redboot.
I appreciate any assistance in explaining the desire and logic behind the decisions which required
this implementation, and any offers of assistance to resolve the situation.
Thanks in advance,
Steve Strublic
sstrublic@hypercom.com
--------
"It only takes one person, one division, one group to change the whole company." --Phillip Crosby's
'Reflections on Quality', #248
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss