Same thing just happened to me. I'm using crossworks with a crossconnect JTAG. Thankfully I found this thread (with a google search, the yahoo group search is pretty useless) before I started punching holes in the drywall.

In this case I was only porting code so I didn't need to do any real debugging on the analog stuff. For future projects it would be nice to have some resolution on this, has anyone been able to use the ADC while debugging?

--- In l..., "joryn81" wrote:
>
> Problem resolved!
>
> This bug was found to be a result of the way in which the Segger J-Link brought up the LPC1768 after programming. It seems that simply programming the micro and then power-cycling the unit allowed for proper ADC operation, with both the code that Martin sent as well as with our own project code.
>
> Unfortunately this means that I cannot debug the Analog portion of the project since I can't power cycle the micro and still have the J-Link happy with debugging, but I am happy that the ADC is now working properly.
>
> Whether this is a problem with the J-Link or with the way that the 1768 boots after initial programming I'm not sure, but I thought I should post so that everyone is aware of the problem. If you were a user coming at this with fresh ADC code and didn't know that this could be a problem you'd beat your head on it for a long time :)
>
> Thanks for all the help, it definitely helped me get to the bottom of things.
>
> Thanks and regards,
> Joe M
>
> --- In l..., "joryn81" wrote:
> >
> > Well a bit of an update on this. Miguel, I tried the code you posted (basically as is, I may post the entirety of my code tomorrow morning for reference) and I was getting the same results on the 2 boards that I have to test with.
> >
> > I'm beginning to suspect that Crossworks itself might be at the heart of the issue. Specifically, it generates some startup code to boot the micro that's a little transparent to the user that might be causing issues. Thinking about this I bypassed the startup code so that the micro should just jump straight into the micro without any preconfiguration. This, unfortunately, didn't fix anything either, but I'm wondering what else Crossworks might be doing that could be causing issues with the way that the micro operates the ADC.
> >
> > Can anyone verify ADC operation under crossworks (or even another GCC compiler)?? Definitely looking to be a tough bug to nail down.
> >
> > Thanks again all,
> > Joe M
> >
> > --- In l..., "capiman26061973" wrote:
> > >
> > > Hello Joe,
> > >
> > > i just took the code from keil, modified it a bit and tried it out in my own project on a keil mcb1700 board (populated with a LPC1768). The following code seems to give me values from potentiometer. Pay attention that Jumper AD0.2 must be closed. Poti is connected to P0.25.
> > >
> > > Here is my code:
> > >
> > > void InitAdc()
> > > {
> > > /* Enable PCSSP0 power. */
> > > PCONP |= (1 << 12);
> > >
> > > PINSEL1 &= ~(0x3 << (2*(25-16))); // Remove all bits, Port P0.25 gets GPIO
> > > PINSEL1 |= (0x1 << (2*(25-16))); // Switch P0.25 to AD0.2
> > >
> > > AD0CR = ( 0x01 << 0 ) | /* SEL=1,select channel 0 on ADC0 */
> > > ( ( 18000000 / 1000000 - 1 ) << 8 ) | /* CLKDIV = Fpclk / ADC_Clk - 1 */
> > > ( 0 << 16 ) | /* BURST = 0, no BURST, software controlled */
> > > ( 0 << 17 ) | /* CLKS = 0, 11 clocks/10 bits */
> > > ( 1 << 21 ) | /* PDN = 1, normal operation */
> > > ( 0 << 24 ) | /* START = 0 A/D conversion stops */
> > > ( 0 << 27 ); /* EDGE = 0 (CAP/MAT singal falling,trigger A/D conversion) */
> > >
> > > }
> > >
> > >
> > > unsigned long ReadAdc()
> > > {
> > > unsigned long regVal, ADC_Data;
> > >
> > > AD0CR &= 0xFFFFFF00;
> > > AD0CR |= (1 << 24) | (1 << 2);
> > >
> > > while ( 1 ) /* wait until end of A/D convert */
> > > {
> > > /* read result of A/D conversion */
> > > regVal = AD0DR2;
> > > if ( (regVal >> 31) & 1 )
> > > {
> > > break;
> > > }
> > > }
> > >
> > > AD0CR &= 0xF8FFFFFF; /* stop ADC now */
> > >
> > > if ( (regVal >> 30) & 1 ) /* save data when it's not overrun, otherwise, return zero */
> > > {
> > > return ( 0 );
> > > }
> > >
> > > ADC_Data = ( regVal >> 4 ) & 0xFFF;
> > >
> > > return ( ADC_Data ); /* return A/D conversion value */
> > > }
> > >
> > > Regards,
> > >
> > > Martin
> > >
> > > --- In l..., "joryn81" wrote:
> > > >
> > > > Hi Martin,
> > > >
> > > > This is actually the demo code from NXP that I was referring to in my original post. Using this code gives me the same results as my own, so either both are broken or neither are :) There doesn't appear to be anything special in the ADC driver for the Keil board so I'm wondering if it was even modified for use on that 1768 (as opposed to just a port of the lpc2000 series code).
> > > >
> > > > Thanks,
> > > > Joe
> > > >
> > > > --- In l..., "capiman26061973" wrote:
> > > > >
> > > > > Hello Joe,
> > > > >
> > > > > > One thing that I've noticed is that the ADC module appears to be
> > > > > > different than the core that was used in the LPC2xxx parts. Since I
> > > > > > can't seem to find any reference to someone using the ADC properly
> > > > > > on these parts I'm wondering if there's some undocumented errata
> > > > > > with these micros.
> > > > >
> > > > > Perhaps you see something in looking into keil ADC code for LPC17xx:
> > > > >
> > > > > http://www.standardics.nxp.com/support/documents/microcontrollers/zip/code.bundle.lpc17xx.keil.zip
> > > > >
> > > > > Regards,
> > > > >
> > > > > Martin
> > > > >
> > > >
> > >
>

Problem resolved!

This bug was found to be a result of the way in which the Segger J-Link brought up the LPC1768 after programming. It seems that simply programming the micro and then power-cycling the unit allowed for proper ADC operation, with both the code that Martin sent as well as with our own project code.

Unfortunately this means that I cannot debug the Analog portion of the project since I can't power cycle the micro and still have the J-Link happy with debugging, but I am happy that the ADC is now working properly.

Whether this is a problem with the J-Link or with the way that the 1768 boots after initial programming I'm not sure, but I thought I should post so that everyone is aware of the problem. If you were a user coming at this with fresh ADC code and didn't know that this could be a problem you'd beat your head on it for a long time :)

Thanks for all the help, it definitely helped me get to the bottom of things.

Thanks and regards,
Joe M

--- In l..., "joryn81" wrote:
>
> Well a bit of an update on this. Miguel, I tried the code you posted (basically as is, I may post the entirety of my code tomorrow morning for reference) and I was getting the same results on the 2 boards that I have to test with.
>
> I'm beginning to suspect that Crossworks itself might be at the heart of the issue. Specifically, it generates some startup code to boot the micro that's a little transparent to the user that might be causing issues. Thinking about this I bypassed the startup code so that the micro should just jump straight into the micro without any preconfiguration. This, unfortunately, didn't fix anything either, but I'm wondering what else Crossworks might be doing that could be causing issues with the way that the micro operates the ADC.
>
> Can anyone verify ADC operation under crossworks (or even another GCC compiler)?? Definitely looking to be a tough bug to nail down.
>
> Thanks again all,
> Joe M
>
> --- In l..., "capiman26061973" wrote:
> >
> > Hello Joe,
> >
> > i just took the code from keil, modified it a bit and tried it out in my own project on a keil mcb1700 board (populated with a LPC1768). The following code seems to give me values from potentiometer. Pay attention that Jumper AD0.2 must be closed. Poti is connected to P0.25.
> >
> > Here is my code:
> >
> > void InitAdc()
> > {
> > /* Enable PCSSP0 power. */
> > PCONP |= (1 << 12);
> >
> > PINSEL1 &= ~(0x3 << (2*(25-16))); // Remove all bits, Port P0.25 gets GPIO
> > PINSEL1 |= (0x1 << (2*(25-16))); // Switch P0.25 to AD0.2
> >
> > AD0CR = ( 0x01 << 0 ) | /* SEL=1,select channel 0 on ADC0 */
> > ( ( 18000000 / 1000000 - 1 ) << 8 ) | /* CLKDIV = Fpclk / ADC_Clk - 1 */
> > ( 0 << 16 ) | /* BURST = 0, no BURST, software controlled */
> > ( 0 << 17 ) | /* CLKS = 0, 11 clocks/10 bits */
> > ( 1 << 21 ) | /* PDN = 1, normal operation */
> > ( 0 << 24 ) | /* START = 0 A/D conversion stops */
> > ( 0 << 27 ); /* EDGE = 0 (CAP/MAT singal falling,trigger A/D conversion) */
> >
> > }
> >
> >
> > unsigned long ReadAdc()
> > {
> > unsigned long regVal, ADC_Data;
> >
> > AD0CR &= 0xFFFFFF00;
> > AD0CR |= (1 << 24) | (1 << 2);
> >
> > while ( 1 ) /* wait until end of A/D convert */
> > {
> > /* read result of A/D conversion */
> > regVal = AD0DR2;
> > if ( (regVal >> 31) & 1 )
> > {
> > break;
> > }
> > }
> >
> > AD0CR &= 0xF8FFFFFF; /* stop ADC now */
> >
> > if ( (regVal >> 30) & 1 ) /* save data when it's not overrun, otherwise, return zero */
> > {
> > return ( 0 );
> > }
> >
> > ADC_Data = ( regVal >> 4 ) & 0xFFF;
> >
> > return ( ADC_Data ); /* return A/D conversion value */
> > }
> >
> > Regards,
> >
> > Martin
> >
> > --- In l..., "joryn81" wrote:
> > >
> > > Hi Martin,
> > >
> > > This is actually the demo code from NXP that I was referring to in my original post. Using this code gives me the same results as my own, so either both are broken or neither are :) There doesn't appear to be anything special in the ADC driver for the Keil board so I'm wondering if it was even modified for use on that 1768 (as opposed to just a port of the lpc2000 series code).
> > >
> > > Thanks,
> > > Joe
> > >
> > > --- In l..., "capiman26061973" wrote:
> > > >
> > > > Hello Joe,
> > > >
> > > > > One thing that I've noticed is that the ADC module appears to be
> > > > > different than the core that was used in the LPC2xxx parts. Since I
> > > > > can't seem to find any reference to someone using the ADC properly
> > > > > on these parts I'm wondering if there's some undocumented errata
> > > > > with these micros.
> > > >
> > > > Perhaps you see something in looking into keil ADC code for LPC17xx:
> > > >
> > > > http://www.standardics.nxp.com/support/documents/microcontrollers/zip/code.bundle.lpc17xx.keil.zip
> > > >
> > > > Regards,
> > > >
> > > > Martin
> > > >
> > >
>

Well a bit of an update on this. Miguel, I tried the code you posted (basically as is, I may post the entirety of my code tomorrow morning for reference) and I was getting the same results on the 2 boards that I have to test with.

I'm beginning to suspect that Crossworks itself might be at the heart of the issue. Specifically, it generates some startup code to boot the micro that's a little transparent to the user that might be causing issues. Thinking about this I bypassed the startup code so that the micro should just jump straight into the micro without any preconfiguration. This, unfortunately, didn't fix anything either, but I'm wondering what else Crossworks might be doing that could be causing issues with the way that the micro operates the ADC.

Can anyone verify ADC operation under crossworks (or even another GCC compiler)?? Definitely looking to be a tough bug to nail down.

Thanks again all,
Joe M

--- In l..., "capiman26061973" wrote:
>
> Hello Joe,
>
> i just took the code from keil, modified it a bit and tried it out in my own project on a keil mcb1700 board (populated with a LPC1768). The following code seems to give me values from potentiometer. Pay attention that Jumper AD0.2 must be closed. Poti is connected to P0.25.
>
> Here is my code:
>
> void InitAdc()
> {
> /* Enable PCSSP0 power. */
> PCONP |= (1 << 12);
>
> PINSEL1 &= ~(0x3 << (2*(25-16))); // Remove all bits, Port P0.25 gets GPIO
> PINSEL1 |= (0x1 << (2*(25-16))); // Switch P0.25 to AD0.2
>
> AD0CR = ( 0x01 << 0 ) | /* SEL=1,select channel 0 on ADC0 */
> ( ( 18000000 / 1000000 - 1 ) << 8 ) | /* CLKDIV = Fpclk / ADC_Clk - 1 */
> ( 0 << 16 ) | /* BURST = 0, no BURST, software controlled */
> ( 0 << 17 ) | /* CLKS = 0, 11 clocks/10 bits */
> ( 1 << 21 ) | /* PDN = 1, normal operation */
> ( 0 << 24 ) | /* START = 0 A/D conversion stops */
> ( 0 << 27 ); /* EDGE = 0 (CAP/MAT singal falling,trigger A/D conversion) */
>
> }
> unsigned long ReadAdc()
> {
> unsigned long regVal, ADC_Data;
>
> AD0CR &= 0xFFFFFF00;
> AD0CR |= (1 << 24) | (1 << 2);
>
> while ( 1 ) /* wait until end of A/D convert */
> {
> /* read result of A/D conversion */
> regVal = AD0DR2;
> if ( (regVal >> 31) & 1 )
> {
> break;
> }
> }
>
> AD0CR &= 0xF8FFFFFF; /* stop ADC now */
>
> if ( (regVal >> 30) & 1 ) /* save data when it's not overrun, otherwise, return zero */
> {
> return ( 0 );
> }
>
> ADC_Data = ( regVal >> 4 ) & 0xFFF;
>
> return ( ADC_Data ); /* return A/D conversion value */
> }
>
> Regards,
>
> Martin
>
> --- In l..., "joryn81" wrote:
> >
> > Hi Martin,
> >
> > This is actually the demo code from NXP that I was referring to in my original post. Using this code gives me the same results as my own, so either both are broken or neither are :) There doesn't appear to be anything special in the ADC driver for the Keil board so I'm wondering if it was even modified for use on that 1768 (as opposed to just a port of the lpc2000 series code).
> >
> > Thanks,
> > Joe
> >
> > --- In l..., "capiman26061973" wrote:
> > >
> > > Hello Joe,
> > >
> > > > One thing that I've noticed is that the ADC module appears to be
> > > > different than the core that was used in the LPC2xxx parts. Since I
> > > > can't seem to find any reference to someone using the ADC properly
> > > > on these parts I'm wondering if there's some undocumented errata
> > > > with these micros.
> > >
> > > Perhaps you see something in looking into keil ADC code for LPC17xx:
> > >
> > > http://www.standardics.nxp.com/support/documents/microcontrollers/zip/code.bundle.lpc17xx.keil.zip
> > >
> > > Regards,
> > >
> > > Martin
> > >
>

--- In l..., Miguel Angel wrote:
>
> Check Gabriel's suggestion about DBGEN pin, may be that's the problem(boundary
> scan enabled).
>
> Gabriel.. so.. if you enable debug, you couldn't use ADC? There is no way to
> fix that?
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
> 2009/9/28 joryn81 >
> >
> > Hi Miguel,
> >
> > I've verified that the VRef pin is connected to 3.3V, only consideration
> > might be that the VRef is not filtered or isolated from the VCC 3.3V. I
> > don't think this would cause problems, but thought it best to mention it.
> >
> > Thanks,
> > Joe
> >
> >
> > --- In l... , Miguel Angel
> > wrote:
> > >
> > > I've only seen this behaviour (in other parts) when not connecting VREF
> > to a
> > > correct reference voltage.
> > >
> > > Check VREF pins voltage.
> > >
> > > Miguel Angel Ajo Pelayo
> > > http://www.nbee.es
> > > +34 91 120 1798
> > > +34 636 52 25 69
> > > skype: ajoajoajo
> > >
> > >
> > > 2009/9/27 joryn81
> > >
> > > >
> > > >
> > > > Hi Charles,
> > > >
> > > > Thanks for the response. Again I should mention that I'm using the NXP
> > > > sample code, as well as some 2368 code of my own that has been ported
> > to
> > > > work with the 1768. The PINSEL registers have all been set and verified
> > > > with the debugger as having been set for the required ADC channels.
> > > >
> > > > One thing that I've noticed is that the ADC module appears to be
> > > > different than the core that was used in the LPC2xxx parts. Since I
> > > > can't seem to find any reference to someone using the ADC properly on
> > > > these parts I'm wondering if there's some undocumented errata with
> > these
> > > > micros.
> > > >
> > > > Keep the feedback coming, anything that comes to mind to try out I'd be
> > > > willing to give a shot. I've pretty much exhausted all my own debugging
> > > > attempts.
> > > >
> > > > Thanks and regards,
> > > > Joe M
> > > >
> > > > --- In l... > > 40yahoogroups.com>, "Charles R.
> > > > Grenz"
> > > > wrote:
> > > >
> > > > > Hi Joe,
> > > > >
> > > > > I'm do not have any experience with the LPC17xx series but it sounds
> > > > > like the configuration control for the ADC channel is still set for
> > > > > I/O. Check your configuration.
> > > > >
> > > > > regards,
> > > > > Charles
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>

HI,

When I checked this isue with NXP, they answered me:

"When Boundary scan is enabled, the device is in a test mode.
Thank you for your feedback. We will try to incorporate this information into future revisions of the documentation."
For debugging through the JTAG interfase you need to set DBGEN = 1.
Boundary scan mode is for factory use (to test the CPU port connections).
Best Regrads,
Gabriel.

Hello Joe,

i just took the code from keil, modified it a bit and tried it out in my own project on a keil mcb1700 board (populated with a LPC1768). The following code seems to give me values from potentiometer. Pay attention that Jumper AD0.2 must be closed. Poti is connected to P0.25.

Here is my code:

void InitAdc()
{
/* Enable PCSSP0 power. */
PCONP |= (1 << 12);

PINSEL1 &= ~(0x3 << (2*(25-16))); // Remove all bits, Port P0.25 gets GPIO
PINSEL1 |= (0x1 << (2*(25-16))); // Switch P0.25 to AD0.2

AD0CR = ( 0x01 << 0 ) | /* SEL=1,select channel 0 on ADC0 */
( ( 18000000 / 1000000 - 1 ) << 8 ) | /* CLKDIV = Fpclk / ADC_Clk - 1 */
( 0 << 16 ) | /* BURST = 0, no BURST, software controlled */
( 0 << 17 ) | /* CLKS = 0, 11 clocks/10 bits */
( 1 << 21 ) | /* PDN = 1, normal operation */
( 0 << 24 ) | /* START = 0 A/D conversion stops */
( 0 << 27 ); /* EDGE = 0 (CAP/MAT singal falling,trigger A/D conversion) */

}
unsigned long ReadAdc()
{
unsigned long regVal, ADC_Data;

AD0CR &= 0xFFFFFF00;
AD0CR |= (1 << 24) | (1 << 2);

while ( 1 ) /* wait until end of A/D convert */
{
/* read result of A/D conversion */
regVal = AD0DR2;
if ( (regVal >> 31) & 1 )
{
break;
}
}

AD0CR &= 0xF8FFFFFF; /* stop ADC now */

if ( (regVal >> 30) & 1 ) /* save data when it's not overrun, otherwise, return zero */
{
return ( 0 );
}

ADC_Data = ( regVal >> 4 ) & 0xFFF;

return ( ADC_Data ); /* return A/D conversion value */
}

Regards,

Martin

--- In l..., "joryn81" wrote:
>
> Hi Martin,
>
> This is actually the demo code from NXP that I was referring to in my original post. Using this code gives me the same results as my own, so either both are broken or neither are :) There doesn't appear to be anything special in the ADC driver for the Keil board so I'm wondering if it was even modified for use on that 1768 (as opposed to just a port of the lpc2000 series code).
>
> Thanks,
> Joe
>
> --- In l..., "capiman26061973" wrote:
> >
> > Hello Joe,
> >
> > > One thing that I've noticed is that the ADC module appears to be
> > > different than the core that was used in the LPC2xxx parts. Since I
> > > can't seem to find any reference to someone using the ADC properly
> > > on these parts I'm wondering if there's some undocumented errata
> > > with these micros.
> >
> > Perhaps you see something in looking into keil ADC code for LPC17xx:
> >
> > http://www.standardics.nxp.com/support/documents/microcontrollers/zip/code.bundle.lpc17xx.keil.zip
> >
> > Regards,
> >
> > Martin
>

I'm using the 100pin LPC1768 part and from what I can see there is no DBGEN pin available on that part. However I should mention that all of my testing so far has been using crossworks in a debugger fashion so is it possible that the 1768 disables the ADCs when it detects a debug build? Bear in mind that the 2368 never exhibited that behavior so it would be pretty surprising if the 1768 did this.

Thanks again to all the input thus far, definitely helpful.
Regards,
Joe M

--- In l..., Miguel Angel wrote:
>
> Check Gabriel's suggestion about DBGEN pin, may be that's the problem(boundary
> scan enabled).
>
> Gabriel.. so.. if you enable debug, you couldn't use ADC? There is no way to
> fix that?
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
> 2009/9/28 joryn81 >
> >
> > Hi Miguel,
> >
> > I've verified that the VRef pin is connected to 3.3V, only consideration
> > might be that the VRef is not filtered or isolated from the VCC 3.3V. I
> > don't think this would cause problems, but thought it best to mention it.
> >
> > Thanks,
> > Joe
> >
> >
> > --- In l... , Miguel Angel
> > wrote:
> > >
> > > I've only seen this behaviour (in other parts) when not connecting VREF
> > to a
> > > correct reference voltage.
> > >
> > > Check VREF pins voltage.
> > >
> > > Miguel Angel Ajo Pelayo
> > > http://www.nbee.es
> > > +34 91 120 1798
> > > +34 636 52 25 69
> > > skype: ajoajoajo
> > >
> > >
> > > 2009/9/27 joryn81
> > >
> > > >
> > > >
> > > > Hi Charles,
> > > >
> > > > Thanks for the response. Again I should mention that I'm using the NXP
> > > > sample code, as well as some 2368 code of my own that has been ported
> > to
> > > > work with the 1768. The PINSEL registers have all been set and verified
> > > > with the debugger as having been set for the required ADC channels.
> > > >
> > > > One thing that I've noticed is that the ADC module appears to be
> > > > different than the core that was used in the LPC2xxx parts. Since I
> > > > can't seem to find any reference to someone using the ADC properly on
> > > > these parts I'm wondering if there's some undocumented errata with
> > these
> > > > micros.
> > > >
> > > > Keep the feedback coming, anything that comes to mind to try out I'd be
> > > > willing to give a shot. I've pretty much exhausted all my own debugging
> > > > attempts.
> > > >
> > > > Thanks and regards,
> > > > Joe M
> > > >
> > > > --- In l... > > 40yahoogroups.com>, "Charles R.
> > > > Grenz"
> > > > wrote:
> > > >
> > > > > Hi Joe,
> > > > >
> > > > > I'm do not have any experience with the LPC17xx series but it sounds
> > > > > like the configuration control for the ADC channel is still set for
> > > > > I/O. Check your configuration.
> > > > >
> > > > > regards,
> > > > > Charles
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>

Check Gabriel's suggestion about DBGEN pin, may be that's the problem(boundary
scan enabled).

Gabriel.. so.. if you enable debug, you couldn't use ADC? There is no way to
fix that?

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/9/28 joryn81

> Hi Miguel,
>
> I've verified that the VRef pin is connected to 3.3V, only consideration
> might be that the VRef is not filtered or isolated from the VCC 3.3V. I
> don't think this would cause problems, but thought it best to mention it.
>
> Thanks,
> Joe
> --- In l... , Miguel Angel
> wrote:
> >
> > I've only seen this behaviour (in other parts) when not connecting VREF
> to a
> > correct reference voltage.
> >
> > Check VREF pins voltage.
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> > 2009/9/27 joryn81
> >
> > >
> > >
> > > Hi Charles,
> > >
> > > Thanks for the response. Again I should mention that I'm using the NXP
> > > sample code, as well as some 2368 code of my own that has been ported
> to
> > > work with the 1768. The PINSEL registers have all been set and verified
> > > with the debugger as having been set for the required ADC channels.
> > >
> > > One thing that I've noticed is that the ADC module appears to be
> > > different than the core that was used in the LPC2xxx parts. Since I
> > > can't seem to find any reference to someone using the ADC properly on
> > > these parts I'm wondering if there's some undocumented errata with
> these
> > > micros.
> > >
> > > Keep the feedback coming, anything that comes to mind to try out I'd be
> > > willing to give a shot. I've pretty much exhausted all my own debugging
> > > attempts.
> > >
> > > Thanks and regards,
> > > Joe M
> > >
> > > --- In l... > 40yahoogroups.com>, "Charles R.
> > > Grenz"
> > > wrote:
> > >
> > > > Hi Joe,
> > > >
> > > > I'm do not have any experience with the LPC17xx series but it sounds
> > > > like the configuration control for the ADC channel is still set for
> > > > I/O. Check your configuration.
> > > >
> > > > regards,
> > > > Charles
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
>

Hi Miguel,

I've verified that the VRef pin is connected to 3.3V, only consideration might be that the VRef is not filtered or isolated from the VCC 3.3V. I don't think this would cause problems, but thought it best to mention it.

Thanks,
Joe

--- In l..., Miguel Angel wrote:
>
> I've only seen this behaviour (in other parts) when not connecting VREF to a
> correct reference voltage.
>
> Check VREF pins voltage.
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
> 2009/9/27 joryn81 >
> >
> > Hi Charles,
> >
> > Thanks for the response. Again I should mention that I'm using the NXP
> > sample code, as well as some 2368 code of my own that has been ported to
> > work with the 1768. The PINSEL registers have all been set and verified
> > with the debugger as having been set for the required ADC channels.
> >
> > One thing that I've noticed is that the ADC module appears to be
> > different than the core that was used in the LPC2xxx parts. Since I
> > can't seem to find any reference to someone using the ADC properly on
> > these parts I'm wondering if there's some undocumented errata with these
> > micros.
> >
> > Keep the feedback coming, anything that comes to mind to try out I'd be
> > willing to give a shot. I've pretty much exhausted all my own debugging
> > attempts.
> >
> > Thanks and regards,
> > Joe M
> >
> > --- In l... , "Charles R.
> > Grenz"
> > wrote:
> >
> > > Hi Joe,
> > >
> > > I'm do not have any experience with the LPC17xx series but it sounds
> > > like the configuration control for the ADC channel is still set for
> > > I/O. Check your configuration.
> > >
> > > regards,
> > > Charles
> > >
> >
> >
> >
>
>

An Engineer's Guide to the LPC2100 Series