EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

LPC2368 GPIO pin state

Started by Kathy Wright October 17, 2008
I've recently moved up to the LPC236x family and need to understand the pin states under all conditions.

I do understand that before pins are assigned as an output, they are all considered inputs. I recall (from somewhere) that they are loosely tied high internally and my probing around indicates that to be the case. This also seems to be the case during Reset (pressing the RESET button on the demo board). Can someone please confirm this or point to me a location where it is explained well?

However, that's only true if there is a valid program. If there isn't a valid program, it goes to the bootloader, and some pins seem to be high, some low (railed), and some 'open'. What happens to the IO pins during this ISP?

Thanks in advance for the help!

Kathy

An Engineer's Guide to the LPC2100 Series

This is the default procedure for processors. They all start as inputs, because is more safe that way. And, in some cases (specially with default pull-ups, the default for LPC) they can start as loosely high.
I came across a specific problem with LPC2368 that costs me about 3 development months, several unanswered mails from this forum and many complains and ugly faces from my boss. At the start of ANY of your programs, force the GPIO PINSEL for GPIO function. In my board, if you don't do that, the board behaves erraticaly and the IO's don't act as outputs, even if ordered to.
Just do that, in the begging of your code, even if this seems stupid, force all PINSEL registers to 0. Works to me as a charm...
--- On Fri, 10/17/08, Kathy Wright wrote:

> From: Kathy Wright
> Subject: [lpc2000] LPC2368 GPIO pin state
> To: l...
> Cc: k...@endwave.com
> Date: Friday, October 17, 2008, 10:40 PM
> I've recently moved up to the LPC236x family and need to
> understand the pin states under all conditions.
>
> I do understand that before pins are assigned as an output,
> they are all considered inputs. I recall (from somewhere)
> that they are loosely tied high internally and my probing
> around indicates that to be the case. This also seems to
> be the case during Reset (pressing the RESET button on the
> demo board). Can someone please confirm this or point to
> me a location where it is explained well?
>
> However, that's only true if there is a valid
> program. If there isn't a valid program, it goes to
> the bootloader, and some pins seem to be high, some low
> (railed), and some 'open'. What happens to the IO
> pins during this ISP?
>
> Thanks in advance for the help!
>
> Kathy
>
>
>
>
>
>
>
>
Thanks Luiz. Forunately a lot of examples I saw explicitly set the
GPIO state so I've done it in the past as well.

Do you have any insight as to what the pin states are during ISP,
before a progam is loaded (and while loading)? Some lines appear to
be forced high or low, and some are inputs loosely tied high. I'll
scan the schematic to see if these correspond to sertian functions
(perhaps UARTs)

Kathy
--- In l..., Luiz Roberto Guimars
wrote:
>
> This is the default procedure for processors. They all start as
inputs, because is more safe that way. And, in some cases (specially
with default pull-ups, the default for LPC) they can start as loosely
high.
> I came across a specific problem with LPC2368 that costs me about 3
development months, several unanswered mails from this forum and many
complains and ugly faces from my boss. At the start of ANY of your
programs, force the GPIO PINSEL for GPIO function. In my board, if
you don't do that, the board behaves erraticaly and the IO's don't
act as outputs, even if ordered to.
> Just do that, in the begging of your code, even if this seems
stupid, force all PINSEL registers to 0. Works to me as a charm...
>
>
> --- On Fri, 10/17/08, Kathy Wright wrote:
>
> > From: Kathy Wright
> > Subject: [lpc2000] LPC2368 GPIO pin state
> > To: l...
> > Cc: kathy.wright@...
> > Date: Friday, October 17, 2008, 10:40 PM
> > I've recently moved up to the LPC236x family and need to
> > understand the pin states under all conditions.
> >
> > I do understand that before pins are assigned as an output,
> > they are all considered inputs. I recall (from somewhere)
> > that they are loosely tied high internally and my probing
> > around indicates that to be the case. This also seems to
> > be the case during Reset (pressing the RESET button on the
> > demo board). Can someone please confirm this or point to
> > me a location where it is explained well?
> >
> > However, that's only true if there is a valid
> > program. If there isn't a valid program, it goes to
> > the bootloader, and some pins seem to be high, some low
> > (railed), and some 'open'. What happens to the IO
> > pins during this ISP?
> >
> > Thanks in advance for the help!
> >
> > Kathy
> >
> >
> >
> >
> >
> >
> >
> >
Mere RC some times doesnot reset the controller.

The 3 terminal chip MCP130T is used in some boards and products.

This Chip is not available off the shelf.

Any suggestion for a tested R-C combinations in lieu of the MCP130T ?

Thanks

Nataraja B V

--- On Mon, 10/20/08, Luiz Roberto Guimars wrote:

From: Luiz Roberto Guimars
Subject: Re: [lpc2000] LPC2368 GPIO pin state
To: l...
Date: Monday, October 20, 2008, 7:40 AM

This is the default procedure for processors. They all start as inputs, because is more safe that way. And, in some cases (specially with default pull-ups, the default for LPC) they can start as loosely high.
I came across a specific problem with LPC2368 that costs me about 3 development months, several unanswered mails from this forum and many complains and ugly faces from my boss. At the start of ANY of your programs, force the GPIO PINSEL for GPIO function. In my board, if you don't do that, the board behaves erraticaly and the IO's don't act as outputs, even if ordered to.
Just do that, in the begging of your code, even if this seems stupid, force all PINSEL registers to 0. Works to me as a charm...

--- On Fri, 10/17/08, Kathy Wright wrote:

> From: Kathy Wright
> Subject: [lpc2000] LPC2368 GPIO pin state
> To: lpc2000@yahoogroups .com
> Cc: kathy.wright@ endwave.com
> Date: Friday, October 17, 2008, 10:40 PM
> I've recently moved up to the LPC236x family and need to
> understand the pin states under all conditions.
>
> I do understand that before pins are assigned as an output,
> they are all considered inputs. I recall (from somewhere)
> that they are loosely tied high internally and my probing
> around indicates that to be the case. This also seems to
> be the case during Reset (pressing the RESET button on the
> demo board). Can someone please confirm this or point to
> me a location where it is explained well?
>
> However, that's only true if there is a valid
> program. If there isn't a valid program, it goes to
> the bootloader, and some pins seem to be high, some low
> (railed), and some 'open'. What happens to the IO
> pins during this ISP?
>
> Thanks in advance for the help!
>
> Kathy
>
>
>
>
>
> ------------ --------- --------- ------
>
>
Well, they "should" behave just like the manual told. But, since they must be explicitly forced, I think they can have any value. Just to cover the basis (and avoid unexpected surprises) it's a good idea put some pull-ups/downs in critical pins...
--- On Mon, 10/20/08, kathy_wright_ca wrote:

> From: kathy_wright_ca
> Subject: [lpc2000] Re: LPC2368 GPIO pin state
> To: l...
> Date: Monday, October 20, 2008, 8:19 PM
> Thanks Luiz. Forunately a lot of examples I saw explicitly
> set the
> GPIO state so I've done it in the past as well.
>
> Do you have any insight as to what the pin states are
> during ISP,
> before a progam is loaded (and while loading)? Some lines
> appear to
> be forced high or low, and some are inputs loosely tied
> high. I'll
> scan the schematic to see if these correspond to sertian
> functions
> (perhaps UARTs)
>
> Kathy
>
>
> --- In l..., Luiz Roberto Guimars
> wrote:
> >
> > This is the default procedure for processors. They all
> start as
> inputs, because is more safe that way. And, in some cases
> (specially
> with default pull-ups, the default for LPC) they can start
> as loosely
> high.
> > I came across a specific problem with LPC2368 that
> costs me about 3
> development months, several unanswered mails from this
> forum and many
> complains and ugly faces from my boss. At the start of ANY
> of your
> programs, force the GPIO PINSEL for GPIO function. In my
> board, if
> you don't do that, the board behaves erraticaly and the
> IO's don't
> act as outputs, even if ordered to.
> > Just do that, in the begging of your code, even if
> this seems
> stupid, force all PINSEL registers to 0. Works to me as a
> charm...
> >
> >
> > --- On Fri, 10/17/08, Kathy Wright
> wrote:
> >
> > > From: Kathy Wright
> > > Subject: [lpc2000] LPC2368 GPIO pin state
> > > To: l...
> > > Cc: kathy.wright@...
> > > Date: Friday, October 17, 2008, 10:40 PM
> > > I've recently moved up to the LPC236x family
> and need to
> > > understand the pin states under all conditions.
> > >
> > > I do understand that before pins are assigned as
> an output,
> > > they are all considered inputs. I recall (from
> somewhere)
> > > that they are loosely tied high internally and my
> probing
> > > around indicates that to be the case. This also
> seems to
> > > be the case during Reset (pressing the RESET
> button on the
> > > demo board). Can someone please confirm this or
> point to
> > > me a location where it is explained well?
> > >
> > > However, that's only true if there is a valid
> > > program. If there isn't a valid program, it
> goes to
> > > the bootloader, and some pins seem to be high,
> some low
> > > (railed), and some 'open'. What happens
> to the IO
> > > pins during this ISP?
> > >
> > > Thanks in advance for the help!
> > >
> > > Kathy
> > >
> > >
> > > [Non-text portions of this message have been
> removed]
> > >
> > >
> > >
> > >
> > >
Natarajan N wrote:
> Mere RC some times doesnot reset the controller.
>
> The 3 terminal chip MCP130T is used in some boards and products.
>
> This Chip is not available off the shelf.

???? Digikey shows 3000+ in stock

Maybe you have a problem with your didtributor

Robert


The 2024 Embedded Online Conference