Re: Fast GPIO on LPC2138/01 - many problems

Started by Alexander Whiplash February 12, 2008
----- Original Message ----
From: Paul Curtis
To: l...
Sent: Tuesday, February 12, 2008 1:24:18 PM
Subject: RE: [lpc2000] Fast GPIO on LPC2138/01 - many problems

Hi,

> I am having quite a few problems with the simplest port IO on this
> LPC2138/01 CPU. I have a complete application running and it is
> almost usable except for not being able to control P0.2 and P0.3 as
> outputs ! These pins appear to be configured properly as outputs but
> are stuck low. I can forcibly pull them high for an instant, so I
> know that the PCB is not shorted. There is no load on them. Also, I
> see the exact same behavior on two different assemblies.

Are these not the I2C pins which are open drain? Isn't this what you'd
expect without any pullups?

-----
Since PINSEL0 = 0 these pins are in GPIO mode and not I2C. In addition, they are being strongly held low which would not be the case for an idle I2C interface. It takes 10's of mA to pull one high. For the purposes of this test there is nothing connected to the pin except an oscilloscope probe.

AW
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

An Engineer's Guide to the LPC2100 Series

Doesn't matter. Still needs pullups.
--- In l..., Alexander Whiplash
wrote:
>
> ----- Original Message ----
> From: Paul Curtis
> To: l...
> Sent: Tuesday, February 12, 2008 1:24:18 PM
> Subject: RE: [lpc2000] Fast GPIO on LPC2138/01 - many problems
>
> Hi,
>
> > I am having quite a few problems with the simplest port IO on this
> > LPC2138/01 CPU. I have a complete application running and it is
> > almost usable except for not being able to control P0.2 and P0.3 as
> > outputs ! These pins appear to be configured properly as outputs but
> > are stuck low. I can forcibly pull them high for an instant, so I
> > know that the PCB is not shorted. There is no load on them. Also, I
> > see the exact same behavior on two different assemblies.
>
> Are these not the I2C pins which are open drain? Isn't this what you'd
> expect without any pullups?
>
> -----
> Since PINSEL0 = 0 these pins are in GPIO mode and not I2C. In
addition, they are being strongly held low which would not be the case
for an idle I2C interface. It takes 10's of mA to pull one high. For
the purposes of this test there is nothing connected to the pin except
an oscilloscope probe.
>
> AW
>
____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
Hi,

> ----- Original Message ----
> From: Paul Curtis
> To: l...
> Sent: Tuesday, February 12, 2008 1:24:18 PM
> Subject: RE: [lpc2000] Fast GPIO on LPC2138/01 - many problems
>
> Hi,
>
> > I am having quite a few problems with the simplest port IO on this
> > LPC2138/01 CPU. I have a complete application running and it is
> > almost usable except for not being able to control P0.2 and P0.3 as
> > outputs ! These pins appear to be configured properly as outputs but
> > are stuck low. I can forcibly pull them high for an instant, so I
> > know that the PCB is not shorted. There is no load on them. Also, I
> > see the exact same behavior on two different assemblies.
>
> Are these not the I2C pins which are open drain? Isn't this what you'd
> expect without any pullups?
>
> -----
> Since PINSEL0 = 0 these pins are in GPIO mode and not I2C.

Doesn't matter. There are no internal pullups on P0.2 and P0.3 hence if you
need to use the for GPIO you require external pullups.

> In addition,
> they are being strongly held low which would not be the case for an
> idle I2C interface. It takes 10's of mA to pull one high. For the
> purposes of this test there is nothing connected to the pin except an
> oscilloscope probe.

So, they stay low when you write 0xc to the GPIO register?

You also say this:

> I might add that if I attempt to read back the FIO0DIR
> register to verify the contents, that it does not match that which I
> have written.

Yeah, what a doozie. Try getting a JTAG adapter that knows how to read
those suckers correctly. We had that problem at one stage, and there's a
particularly nasty bugette in the NXP silicon that causes this type of
behaviour. I don't believe it's even documented, we didn't bother reporting
it. The Segger J-Link works around this in a rather complex way, if that's
of help, but I can't honestly say that the current firmware/DLL will work
correctly with it--you'd need to test it out.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
--- In l..., Alexander Whiplash
wrote:
>
> ----- Original Message ----
> From: Paul Curtis
> To: l...
> Sent: Tuesday, February 12, 2008 1:24:18 PM
> Subject: RE: [lpc2000] Fast GPIO on LPC2138/01 - many problems
>
> Hi,
>
> > I am having quite a few problems with the simplest port IO on this
> > LPC2138/01 CPU. I have a complete application running and it is
> > almost usable except for not being able to control P0.2 and P0.3 as
> > outputs ! These pins appear to be configured properly as outputs but
> > are stuck low. I can forcibly pull them high for an instant, so I
> > know that the PCB is not shorted. There is no load on them. Also, I
> > see the exact same behavior on two different assemblies.
>
> Are these not the I2C pins which are open drain? Isn't this what you'd
> expect without any pullups?
>
> -----
> Since PINSEL0 = 0 these pins are in GPIO mode and not I2C. In
addition, they are being strongly held low which would not be the case
for an idle I2C interface. It takes 10's of mA to pull one high. For
the purposes of this test there is nothing connected to the pin except
an oscilloscope probe.
>
> AW

Hi

Paul is right these are I2C pins so they are open-drain.This kind of
questions were asked many time here.Here's what user manual has to say
it about those pins;
"Open-drain 5 V tolerant digital I/O I2C-bus 400 kHz specification
compatible pad. It requires external pull-up to provide an output
functionality"