Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: GPIO read bug fixed in 2114/2124?

2004-04-12 by Lee Studley

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.