MPC5200B: Trouble with config pins

MPC5200B: Trouble with config pins

[Juergen Beisert]

Hi all,

we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200=
B=20
CPU. These pins act as the interface to an external phy and also act as=20
configurations pins to configure the size of the flash and other things.=20
While the reset is active these pins should be in their high impedance stat=
e=20
and the externally connected pull down resistors should define wire's volta=
ge=20
level. With the rising edge of the reset signal these levels will be latche=
d=20
into internal config registers.
We are in trouble when we want to reboot the system (also watchdog based) o=
r=20
the internal watchdog barks and generates the CPU internal reset signal. In=
=20
these cases these config pins will not change their level! So the wrong=20
settings are latched in and our CPU is dead (misconfigured), sometimes a=20
second reset helps, but most of the time only power cycling helps.

What we see is:
 - at the pins ETH_0 and ETH_3 (both are output only, when used for
   ethernet)

 * With an external 10k pulldown these lines never change their 3.3V level
   even if the reset is active!
 * With an external 1k pulldown these lines change their 3.3V level down to
   something about 2.5V when the falling edge of the reset signal occurs.
 * This level decreases slowly to 1.2V in about 1.2ms and than a falling ed=
ge
   to 0V occures. Problem here is, the internal watchdog's generated reset
   signal is much shorter, so the rising edge of this reset signal also
   latches in the wrong settings and the CPU is dead.

Some other things we see. A reset while:
 - a running tftp command in U-Boot with disconnected network
    -> system is always dead
 - a running tftp command in U-Boot with connected network
    -> system restarts
   We can see in this case, the ETH_0 and ETH_3 are switching to low
   level *immediatly* with the falling edge of the reset signal
 - an activated interface ("ifconfig up") in Linux with *disconnected* netw=
ork
    -> system is always dead
 - an activated interface ("ifconfig up") in Linux with *connected* network
    -> system is always dead

Does anybody see a behaviour like ours on his/her MPC5200B based system?
Does anybody have an idea what the difference between U-Boot und Linux coul=
d=20
be? Bug? Feature?

Regards,
Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: [U-Boot] MPC5200B: Trouble with config pins

[Grant Likely]

Juergen, I haven't seen this behaviour.  Have you asked you Freescale FAE?

Hey John, have you ever seen this sort of issue?

g.

On Fri, Nov 21, 2008 at 5:36 AM, Juergen Beisert <jbe@pengutronix.de> wrote:
> Hi all,
>
> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B
> CPU. These pins act as the interface to an external phy and also act as
> configurations pins to configure the size of the flash and other things.
> While the reset is active these pins should be in their high impedance state
> and the externally connected pull down resistors should define wire's voltage
> level. With the rising edge of the reset signal these levels will be latched
> into internal config registers.
> We are in trouble when we want to reboot the system (also watchdog based) or
> the internal watchdog barks and generates the CPU internal reset signal. In
> these cases these config pins will not change their level! So the wrong
> settings are latched in and our CPU is dead (misconfigured), sometimes a
> second reset helps, but most of the time only power cycling helps.
>
> What we see is:
>  - at the pins ETH_0 and ETH_3 (both are output only, when used for
>   ethernet)
>
>  * With an external 10k pulldown these lines never change their 3.3V level
>   even if the reset is active!
>  * With an external 1k pulldown these lines change their 3.3V level down to
>   something about 2.5V when the falling edge of the reset signal occurs.
>  * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge
>   to 0V occures. Problem here is, the internal watchdog's generated reset
>   signal is much shorter, so the rising edge of this reset signal also
>   latches in the wrong settings and the CPU is dead.
>
> Some other things we see. A reset while:
>  - a running tftp command in U-Boot with disconnected network
>    -> system is always dead
>  - a running tftp command in U-Boot with connected network
>    -> system restarts
>   We can see in this case, the ETH_0 and ETH_3 are switching to low
>   level *immediatly* with the falling edge of the reset signal
>  - an activated interface ("ifconfig up") in Linux with *disconnected* network
>    -> system is always dead
>  - an activated interface ("ifconfig up") in Linux with *connected* network
>    -> system is always dead
>
> Does anybody see a behaviour like ours on his/her MPC5200B based system?
> Does anybody have an idea what the difference between U-Boot und Linux could
> be? Bug? Feature?
>
> Regards,
> Juergen
>
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
>     Handelsregister: Amtsgericht Hildesheim, HRA 2686
>          Vertretung Sued/Muenchen, Germany
>   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [U-Boot] MPC5200B: Trouble with config pins

[Juergen Beisert]

Hi Grant,

On Freitag, 21. November 2008, Grant Likely wrote:
> Juergen, I haven't seen this behaviour.  Have you asked you Freescale FAE?

Yes. But no answer yet. Thats why I ask here.

Regards,
Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

Re: [U-Boot] MPC5200B: Trouble with config pins

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]


On Fri, Nov 21, 2008 at 08:09:20AM -0700, Grant Likely wrote:

> Juergen, I haven't seen this behaviour.  Have you asked you Freescale FAE?
> 
> Hey John, have you ever seen this sort of issue?

To keep you updated: It was the PHY which would drive the lines high if
the reset signal was "too long". Next revision of the PHY will have this
fixed. (Yeah, next revision, sigh...)

All the best,

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: MPC5200B: Trouble with config pins

[Andre Schwarz]

J=FCrgen,

Have a look at the manual chapter 4 (=3DReset + Config).
SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware=20
reset.
Looks like you should make use of the SRESET and trigger HRESET according=
ly.

I could solve this with _not_ using the internal watchdog but an=20
external one (TPS3828),
i.e. watchdog timeouts and reboots are always issued by PORESET.



regards,
Andre


Juergen Beisert schrieb:
> Hi all,
>
> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC=
5200B=20
> CPU. These pins act as the interface to an external phy and also act as=
=20
> configurations pins to configure the size of the flash and other things=
.=20
> While the reset is active these pins should be in their high impedance =
state=20
> and the externally connected pull down resistors should define wire's v=
oltage=20
> level. With the rising edge of the reset signal these levels will be la=
tched=20
> into internal config registers.
> We are in trouble when we want to reboot the system (also watchdog base=
d) or=20
> the internal watchdog barks and generates the CPU internal reset signal=
. In=20
> these cases these config pins will not change their level! So the wrong=
=20
> settings are latched in and our CPU is dead (misconfigured), sometimes =
a=20
> second reset helps, but most of the time only power cycling helps.
>
> What we see is:
>  - at the pins ETH_0 and ETH_3 (both are output only, when used for
>    ethernet)
>
>  * With an external 10k pulldown these lines never change their 3.3V le=
vel
>    even if the reset is active!
>  * With an external 1k pulldown these lines change their 3.3V level dow=
n to
>    something about 2.5V when the falling edge of the reset signal occur=
s.
>  * This level decreases slowly to 1.2V in about 1.2ms and than a fallin=
g edge
>    to 0V occures. Problem here is, the internal watchdog's generated re=
set
>    signal is much shorter, so the rising edge of this reset signal also
>    latches in the wrong settings and the CPU is dead.
>
> Some other things we see. A reset while:
>  - a running tftp command in U-Boot with disconnected network
>     -> system is always dead
>  - a running tftp command in U-Boot with connected network
>     -> system restarts
>    We can see in this case, the ETH_0 and ETH_3 are switching to low
>    level *immediatly* with the falling edge of the reset signal
>  - an activated interface ("ifconfig up") in Linux with *disconnected* =
network
>     -> system is always dead
>  - an activated interface ("ifconfig up") in Linux with *connected* net=
work
>     -> system is always dead
>
> Does anybody see a behaviour like ours on his/her MPC5200B based system=
?
> Does anybody have an idea what the difference between U-Boot und Linux =
could=20
> be? Bug? Feature?
>
> Regards,
> Juergen
>
>  =20


MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: MPC5200B: Trouble with config pins

[Juergen Beisert]

Hi Andre,

On Freitag, 21. November 2008, Andre Schwarz wrote:
> Have a look at the manual chapter 4 (=3DReset + Config).
> SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
> reset.
> Looks like you should make use of the SRESET and trigger HRESET
> accordingly.
>
> I could solve this with _not_ using the internal watchdog but an
> external one (TPS3828),
> i.e. watchdog timeouts and reboots are always issued by PORESET.

We are using an external watchdog now. But same behaviour. It hurts less,=20
because we increase the length of the active reset signal to add more time =
to=20
let the pin "find" its low level. But I'm not really happy about this=20
solution...

Regards,
Juergen

=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0   Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0    Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9