LPC2132 PWM6/GPIO Bug?

Started by sig5534 December 2, 2006
I am using the LPC2132/QFN64 on a project, where I have the PWM6 on
Pin P0.9 (34) used as well as a GPIO output on Pin 0.10 (35). If I
setup the P0.9 PWM6 on the PINSEL0, the GPIO output on P0.10 stops
working! It is locked at LO output. If I set P0.9 for GPIO out or
in, then P0.10 works fine.

I've checked over my code now several times but there just isn't that
much involved and I can find no explanation for this. Using the PWM6
on P0.9 appears to kill the GPIO output on P0.10. Nothing about this
in the Errata.

Has anyone run into this? I'm open to ideas.

Chris.

An Engineer's Guide to the LPC2100 Series

On Sat, 02 Dec 2006 10:30:56 -0000, you wrote:

>I am using the LPC2132/QFN64 on a project, where I have the PWM6 on
>Pin P0.9 (34) used as well as a GPIO output on Pin 0.10 (35). If I
>setup the P0.9 PWM6 on the PINSEL0, the GPIO output on P0.10 stops
>working! It is locked at LO output. If I set P0.9 for GPIO out or
>in, then P0.10 works fine.
>
>I've checked over my code now several times but there just isn't that
>much involved and I can find no explanation for this. Using the PWM6
>on P0.9 appears to kill the GPIO output on P0.10. Nothing about this
>in the Errata.
>
>Has anyone run into this? I'm open to ideas.
>
>Chris.

Don't know how possible it is in this situation, but last time I saw a similarly strange thing (
this was on AVR), I eventually tracked it down to a typo in the processor-specific header file from
the manufacturer, which had the wrong address for a moderately obscure bit in an IO register.

Always look at the actual code generated to make sure it is doing what you think it should be....

Also, try writing a minimal application code image that just tests the specific issue, to eliminate
things like compiler bugs. ( also easier to check that the compiler is generating the correct code.)

This sort of thing is more likely than silicon bugs. (and fortunately easier to fix..!)
--- In l..., "sig5534" wrote:
>
> I am using the LPC2132/QFN64 on a project, where I have the PWM6 on
> Pin P0.9 (34) used as well as a GPIO output on Pin 0.10 (35). If I
> setup the P0.9 PWM6 on the PINSEL0, the GPIO output on P0.10 stops
> working! It is locked at LO output. If I set P0.9 for GPIO out or
> in, then P0.10 works fine.
>
> I've checked over my code now several times but there just isn't that
> much involved and I can find no explanation for this. Using the PWM6
> on P0.9 appears to kill the GPIO output on P0.10. Nothing about this
> in the Errata.
>
> Has anyone run into this? I'm open to ideas.
>
> Chris.
>

Trace all the writes to PINSEL0 in your code and verify the content of
PINSEL0 after the last write.
Yeah the header file was the problem. Where ever I got this from it appears the default constants were binary:

#define P09_F1_RXD1 ( 1 <<18) // Pin09, F1, RXD1
#define P09_F2_PWM6 (10 <<18) // Pin09, F2, PWM6
#define P09_F3_EINT3 (11 <<18) // Pin09, F3, EINT3

In GCC these are decimal: 1, 10, 11. I changed all of them to hex and that fixed it:

#define P09_F1_RXD1 (0x1 <<18) // Pin09, F1, RXD1
#define P09_F2_PWM6 (0x2 <<18) // Pin09, F2, PWM6
#define P09_F3_EINT3 (0x3 <<18) // Pin09, F3, EINT3

Chris.

----- Original Message -----
From: Mike Harrison
To: l...
Sent: Saturday, December 02, 2006 2:50 AM
Subject: Re: [lpc2000] LPC2132 PWM6/GPIO Bug?
On Sat, 02 Dec 2006 10:30:56 -0000, you wrote:

>I am using the LPC2132/QFN64 on a project, where I have the PWM6 on
>Pin P0.9 (34) used as well as a GPIO output on Pin 0.10 (35). If I
>setup the P0.9 PWM6 on the PINSEL0, the GPIO output on P0.10 stops
>working! It is locked at LO output. If I set P0.9 for GPIO out or
>in, then P0.10 works fine.
>
>I've checked over my code now several times but there just isn't that
>much involved and I can find no explanation for this. Using the PWM6
>on P0.9 appears to kill the GPIO output on P0.10. Nothing about this
>in the Errata.
>
>Has anyone run into this? I'm open to ideas.
>
>Chris.

Don't know how possible it is in this situation, but last time I saw a similarly strange thing (
this was on AVR), I eventually tracked it down to a typo in the processor-specific header file from
the manufacturer, which had the wrong address for a moderately obscure bit in an IO register.

Always look at the actual code generated to make sure it is doing what you think it should be....

Also, try writing a minimal application code image that just tests the specific issue, to eliminate
things like compiler bugs. ( also easier to check that the compiler is generating the correct code.)

This sort of thing is more likely than silicon bugs. (and fortunately easier to fix..!)