This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]