Lpc2000

As was discussed in an earlier thread, there is an undocumented
bug in the LPC2106 that prevents the GPIO pins from being read
if they are configured for an alternative use (even though
the Philips documentation explicitly says that it will work).

But I need to know if the same problem exists in the LPC2114/2124.
Since the 2114/2124 came to market after the 2106, maybe there is
a chance that the bug was discovered and fixed.

Does anyone know?

     -bob

Hi Bob,
I wouldnt really say this is a hardware bug, but a documentation bug.
Muxing of the pin would account for the loss of the pin level status
which is up to the chip arch designer. Sounds like the docs people 
didnt pay attention to the hardware guys. When I worked for 
Microchip and others this stuff was common. Usually the design will
be cookie cuttered into similar micros designs and to keep from
having to redo the chip masks etc. But my personal opinion is that
if an alternate function is selected, being able to read a pin level
is a secondary vestige that is normally an option to depend on. But 
of course, I may be wrong :-)

Can you switch to GPIO, then get the level, then back as needed? 
Or will this cause a glitch.

-Lee

--- In lpc2000@yahoogroups.com, "bobbruce000" <bobbruce000@y...> 
wrote:

> As was discussed in an earlier thread, there is an undocumented
> bug in the LPC2106 that prevents the GPIO pins from being read
> if they are configured for an alternative use (even though
> the Philips documentation explicitly says that it will work).
> 
> But I need to know if the same problem exists in the LPC2114/2124.
> Since the 2114/2124 came to market after the 2106, maybe there is
> a chance that the bug was discovered and fixed.
> 
> Does anyone know?
> 
>      -bob

Meant top say"
if an alternate function is selected, being able to read a pin level
is a secondary vestige that is normally an option *NOT* to depend 
on. But
of course, I may be wrong :-)

--- In lpc2000@yahoogroups.com, "Lee Studley" <indigo_red@q...> 
wrote:
> Hi Bob,
> I wouldnt really say this is a hardware bug, but a documentation 
bug.
> Muxing of the pin would account for the loss of the pin level 
status
> which is up to the chip arch designer. Sounds like the docs people 
> didnt pay attention to the hardware guys. When I worked for 
> Microchip and others this stuff was common. Usually the design will
> be cookie cuttered into similar micros designs and to keep from
> having to redo the chip masks etc. But my personal opinion is that
> if an alternate function is selected, being able to read a pin 
level
> is a secondary vestige that is normally an option to depend on. 
But 
> of course, I may be wrong :-)
> 
> Can you switch to GPIO, then get the level, then back as needed? 
> Or will this cause a glitch.
> 
> -Lee
> 
> --- In lpc2000@yahoogroups.com, "bobbruce000" <bobbruce000@y...> 
> wrote:
> > As was discussed in an earlier thread, there is an undocumented
> > bug in the LPC2106 that prevents the GPIO pins from being read
> > if they are configured for an alternative use (even though
> > the Philips documentation explicitly says that it will work).
> > 
> > But I need to know if the same problem exists in the 
LPC2114/2124.

> > Since the 2114/2124 came to market after the 2106, maybe there is
> > a chance that the bug was discovered and fixed.
> > 
> > Does anyone know?
> > 
> >      -bob

--- In lpc2000@yahoogroups.com, "Lee Studley" <indigo_red@q...> wrote:
> Hi Bob,
> I wouldnt really say this is a hardware bug, but a documentation
> bug.

I guess that is one way to look at it.  So let me rephrase my
question:

   The LPC2106 docs contain a bug, when they state that the pins
   are readable even if an alternate funcion is enabled.

   The LPC2114 docs contain the same statement.  But is this
   another "documentation bug", or does it accurately reflect
   what the hardware actually does?

Happy now? ;-)
 
> Can you switch to GPIO, then get the level, then back as needed? 
> Or will this cause a glitch.

No.  I cannot think of any way to do that reliably.  There is always
a chance of missing a transition.

The only solution I can think of, is to dedicate additional pins,
and have the signal go to a capture pin and also to a GPIO pin.
Since I will have eight capture signals, that means I need to give
up eight other pins, that I would rather use for other purposes.
But I need to know before I etch a board, which is why I am asking.

    -bob

I can barely spell so never take me seriously, so yep :-) I agree 
its frustrating when its not defined well. 


--- In lpc2000@yahoogroups.com, "bobbruce000" <bobbruce000@y...> 
wrote:
> --- In lpc2000@yahoogroups.com, "Lee Studley" <indigo_red@q...> 
wrote:
> > Hi Bob,
> > I wouldnt really say this is a hardware bug, but a documentation
> > bug.
> 
> I guess that is one way to look at it.  So let me rephrase my
> question:
> 
>    The LPC2106 docs contain a bug, when they state that the pins
>    are readable even if an alternate funcion is enabled.
> 
>    The LPC2114 docs contain the same statement.  But is this
>    another "documentation bug", or does it accurately reflect
>    what the hardware actually does?
> 
> Happy now? ;-)
>  
> > Can you switch to GPIO, then get the level, then back as needed? 
> > Or will this cause a glitch.
> 
> No.  I cannot think of any way to do that reliably.  There is 
always

> a chance of missing a transition.
> 
> The only solution I can think of, is to dedicate additional pins,
> and have the signal go to a capture pin and also to a GPIO pin.
> Since I will have eight capture signals, that means I need to give
> up eight other pins, that I would rather use for other purposes.
> But I need to know before I etch a board, which is why I am asking.
> 
>     -bob

Hello Bob,

As it can be seen from user manuals that are accompanying LPC2000 
microcontrollers, port pins can be configured to perform one out of 
up to four digital/analog functions, GPIO pin function being one of 
them. 

In case of the LPC2114/2124 part, the one you are working with, the 
IOPIN register described in the "Table 68: GPIO Register Map" 
("LPC2114/2124/2212/2214 User Manual", page 110, February 03, 2004 
edition) refers to IOPIN as "GPIO Port Pin value register", and not 
to the "Port Pin value
" in general. More detailed description of the 
same register (page 111), starts with: 

"This register provides the value of the GPIO pins
"

Therefore, IOPIN reflects any outside world influence on the GPIO 
configured pins only! Monitoring of non-GPIO configured port pins 
using IOPIN register will not be valid, since activities on non-GPIO 
pins are not indicated in the IOPIN register.

Selection of a single function on a port pin completely excludes all 
other functions otherwise available on the same pin.

The only partial exception to the above rule of exclusion is in the 
case of inputs to the A/D converter. Regardless of the function that 
is selected for the port pin that also hosts the A/D input, this A/D 
input can be read at any time and variations of the voltage level on 
this pin will be reflected in the A/D readings. However, valid analog 
reading(s) can be obtained if and only if the function of an analog 
input is selected. Only in this case proper interface circuit is 
active in between the physical pin and the A/D module. In all other 
cases, a part of digital logic necessary for the digital function to 
be performed will be active, and will disrupt proper behavior of the 
A/D.

This is the way all ports in Philips LPC2000 family of 
microcontrollers are designed to operate. 

Hope this clarifies the subject of GPIO pins. 

Philips apps.




--- In lpc2000@yahoogroups.com, "bobbruce000" <bobbruce000@y...> 
wrote:
> --- In lpc2000@yahoogroups.com, "Lee Studley" <indigo_red@q...> 
wrote:

> > Hi Bob,
> > I wouldnt really say this is a hardware bug, but a documentation
> > bug.
> 
> I guess that is one way to look at it.  So let me rephrase my
> question:
> 
>    The LPC2106 docs contain a bug, when they state that the pins
>    are readable even if an alternate funcion is enabled.
> 
>    The LPC2114 docs contain the same statement.  But is this
>    another "documentation bug", or does it accurately reflect
>    what the hardware actually does?
> 
> Happy now? ;-)
>  
> > Can you switch to GPIO, then get the level, then back as needed? 
> > Or will this cause a glitch.
> 
> No.  I cannot think of any way to do that reliably.  There is always
> a chance of missing a transition.
> 
> The only solution I can think of, is to dedicate additional pins,
> and have the signal go to a capture pin and also to a GPIO pin.
> Since I will have eight capture signals, that means I need to give
> up eight other pins, that I would rather use for other purposes.
> But I need to know before I etch a board, which is why I am asking.
> 
>     -bob

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote: 
> In case of the LPC2114/2124 part, the one you are working with, the 
> IOPIN register described in the "Table 68: GPIO Register Map" 
> ("LPC2114/2124/2212/2214 User Manual", page 110, February 03, 2004 
> edition) refers to IOPIN as "GPIO Port Pin value register", and not 
> to the "Port Pin value…" in general. More detailed description of
> the same register (page 111), starts with: 
> 
> "This register provides the value of the GPIO pins…"
> 
> Therefore, IOPIN reflects any outside world influence on the GPIO 
> configured pins only!

This may very well be the way the hardware works (and I will take
your word for it).  But claiming that this is what the documentation
says is baloney.  Try reading page 110.  I quote (capitalized emphasis
is mine):

IOPIN:  .... The current state of the port pins can always be read
         from this register, REGARDLESS OF PIN DIRECTION OR MODE.

> This is the way all ports in Philips LPC2000 family of
> microcontrollers are designed to operate. 
> 
> Hope this clarifies the subject of GPIO pins. 

It clarifies it for me.  But that won't help the next person who
downloads the documentation, and believes it is accurate.

    -bob

Bob,

the wording (though correct) is nor explicitely clear. We will update 
and clarify the documentation.
In regards to the implementation, I would like to apologize because 
it does not help a lot for applications that want to read the status 
of ALL port pins (no matter how configured).
Unfortunately for now and the near future we will have to live with 
it and we will make the best attempt to describe the (non)
functionality more clear.

Best regards, Robert

p.s. postings from philips_apps are from different people in our 
applications team as mentioned in one of my first postings. We try 
our best to keep this group informed even before we can update 
documentation which is a (too) lengthy process

--- In lpc2000@yahoogroups.com, "bobbruce000" <bobbruce000@y...> 
wrote:
> --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote: 
> > In case of the LPC2114/2124 part, the one you are working with, 
the 
> > IOPIN register described in the "Table 68: GPIO Register Map" 
> > ("LPC2114/2124/2212/2214 User Manual", page 110, February 03, 
2004 
> > edition) refers to IOPIN as "GPIO Port Pin value register", and 
not 
> > to the "Port Pin value
" in general. More detailed description of
> > the same register (page 111), starts with: 
> > 
> > "This register provides the value of the GPIO pins
"
> > 
> > Therefore, IOPIN reflects any outside world influence on the GPIO 
> > configured pins only!
> 
> This may very well be the way the hardware works (and I will take
> your word for it).  But claiming that this is what the documentation
> says is baloney.  Try reading page 110.  I quote (capitalized 
emphasis

> is mine):
> 
> IOPIN:  .... The current state of the port pins can always be read
>          from this register, REGARDLESS OF PIN DIRECTION OR MODE.
> 
> > This is the way all ports in Philips LPC2000 family of
> > microcontrollers are designed to operate. 
> > 
> > Hope this clarifies the subject of GPIO pins. 
> 
> It clarifies it for me.  But that won't help the next person who
> downloads the documentation, and believes it is accurate.
> 
>     -bob