--- In l..., tike64 wrote: > I'm trying to get the ADC of the LPC2468 working
but have
> had no luck so far. The result is always zero...
With joy and happy I can tell that the problem is solved. The solution
is as simple as keeping the DBGEN signal high and selecting the
relevant pins for ADC.
DBGEN pin being low seems to disconnect ADC from pins. The same seems
to happen to internal pullups also. I didn't find any mention from the
documentation about this.
About selecting the pin functions UM promptly says that you don't have
to do that, that ADC is always connected to the pins. This proved to
be false.
In the course I tested these two possibilities many times among many
other things but apparently not at the same time. NXP kindly took our
board and proved that there is nothing wrong with the board nor with
the chip. They didn't see no problem at all because they had to pull
the DBGEN low for JTAG debugger. I didn't use JTAG debugger, but when
I saw the working board I got immediate revelation...
Hopefully this saves someone other from the same kind of grief.
Thanks for the group for trying to help: Rolf, Brendan, Leon, Zdravko,
Chris, boB, Robert, Karl, Mark and Niels
This may be a wee bit off topic, but on my PCB, I replaced
the LPC2144 chip a couple of times, and the part I have
on that board now has a noise problem in the A/D channel
zero at least. The DC voltage reading won't sit still
like it does in all the other boards I have.
Just an FYI. The parts "CAN" be faulty sometimes.
I also found that I have to put a bigger electrolytic
cap across one of the 3.3V bypass caps for the other
LPC214x parts to be steady. I also bypass the A/D
reference pretty well. Evidently the LPC214x power
supply ripple will mix in with the other voltages (or
ground) and give confusing A/D results if the board
layout isn't perfect.
boB
--- In l..., Rolf Meeser wrote: >
> Hi Timo,
>
> yes, it runs on the LPC2468 board from Embedded
> Artists.
>
> Rolf
> --- tike64 schrieb:
>
> > --- rolfm_9dq wrote:
> > > please try this code, tested on an LPC2468.
> >
> > Output is full of zeros...
> >
> > Do you have a working LPC2468 system?
> >
> > --
> >
> > Timo
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Sucker-punch spam with award-winning protection.
> > Try the free Yahoo! Mail Beta.
> >
> http://advision.webevents.yahoo.com/mailbeta/features_spam.html
> > __________________________________ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever >
Reply by Rolf Meeser●May 12, 20072007-05-12
Hi Timo,
yes, it runs on the LPC2468 board from Embedded
Artists.
Rolf
--- tike64 schrieb:
> --- rolfm_9dq wrote:
> > please try this code, tested on an LPC2468.
>
> Output is full of zeros...
>
> Do you have a working LPC2468 system?
>
> --
>
> Timo
>
>
> ____________________________________________________________________________________ > Sucker-punch spam with award-winning protection.
> Try the free Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/features_spam.html >
__________________________________ Yahoo! Clever: Sie haben Fragen?
Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever
Reply by tike64●May 11, 20072007-05-11
--- rolfm_9dq wrote: > please try this code, tested on an LPC2468.
--- In l..., tike64 wrote: > Given, that even NXP itself hadn't anything more
to offer than a
> LPC2368 binary, I'm starting to wonder if there was even one working
> LPC2468 device out there.
>
Hi Timo,
please try this code, tested on an LPC2468.
It's a modified version of your original post.
(It assumes CCLK = 48 MHz, PCLK(ADC) = 12 MHz)
Please note, that you have to wait for the DONE bit to get set.
Rolf
int main( void )
{
int i;
int adc;
uint32_t gdr;
// UART1 for printf
fnUart1Init();
// Connect ADC inputs
// (Only AD0.0 and AD0.1 on available hardware platform)
PINSEL1 = (PINSEL1 & ~0x0003C000) | 0x00014000;
// Enable ADC clock
PCONP |= 1 << 12;
// Run single conversion on several ADC inputs
adc = 0;
while( 1 )
{
// Start conversion
AD0CR = 0x01200200 | (1 << adc);
// End of conversion?
while( !((gdr = AD0GDR) & 0x80000000) )
;
// Show result
printf( "AD0.%d = %d\n",
(int)((gdr >> 24) & 7),
(int)((gdr >> 6) & 0x3FF) );
// Wait before starting the conversion on the next channel
for( i = 0 ; i < 1000000 ; i++ )
;
// Next channel
adc = (adc + 1) % 8;
}
}
Reply by tike64●May 11, 20072007-05-11
--- Brendan Murphy wrote: > It needn't be an ADC pin that a 5V i/p can cause
problems.
>
> We discovered this a long time ago (before it was documented
> anywhere): we had a 5V UART interface, but because one of the pins on
>
> this could also be configured as an ADC it interfered with the entire
>
> ADC operation.
>
> Note this could be a complete red herring, as I don't know if this
> problem is present on the LPC2468 (and/or you mightn't have any 5V
> anywhere).
Thanks for the suggestions (to also Zdravko and others).
We measured all the pins and indeed we have some pins fed with 5V and
some with 3.45V. They are not the pins of the AD module, though.
Anyway, I programmed them all as logic low outputs (they are fed
through resistors) to prevent the overvoltage. undervoltages we didn't
found (Zdravko's suggestion). But nothing changed.
I also got a binary sample program from NXP which was supposed to work
at least on a LPC2368 board. That one too was unable to show anything
but zero.
Given, that even NXP itself hadn't anything more to offer than a
LPC2368 binary, I'm starting to wonder if there was even one working
LPC2468 device out there.
--
Timo
____________________________________________________________________________________Take
the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
Reply by 3gpabko●May 9, 20072007-05-09
--- tike64 wrote: > ADC-inputs are mostly at ground (I have measured) and I exercise
them > with about 2V.
>
One more suggestion. Recently we have a problem on one
of our boards because of a small negative voltage on
one of the ADC inputs( apr. -0.1 V). The result was
that any ADC measurement on any of the channels was
zero.
--- In l..., tike64 wrote: > > - Do you have any voltage more than 3.3V on any
pin? There was a
> > problem on some parts where even though pins were 5V tolerent, if the > > pin was shared with a ADC i/p, even if the ADC was
on a different
> > pin, the conversion gave the wrong result. This may have been fixed, > > though.
>
> ADC-inputs are mostly at ground (I have measured) and I exercise them > with about 2V.
>
It needn't be an ADC pin that a 5V i/p can cause problems.
We discovered this a long time ago (before it was documented
anywhere): we had a 5V UART interface, but because one of the pins on
this could also be configured as an ADC it interfered with the entire
ADC operation.
Note this could be a complete red herring, as I don't know if this
problem is present on the LPC2468 (and/or you mightn't have any 5V
anywhere).
Brendan
Reply by tike64●May 9, 20072007-05-09
--- Brendan Murphy wrote: > Two other things I'd check:
>
> - Check out the assembler code generated to make sure it's doing what
> you think it is. In particular that code isn't optimised away or the
> struct type cast does what you expect (I'd never use a struct type
> cast to map to hardware registers by the way, as it's too compiler
> dependent). Simplest might be to turn the optimiser off.
Yes, I have read the code with objdump and debugger and optimization is
absent. I think a further proof is that the DONE bits function as
expected.
> - Do you have any voltage more than 3.3V on any pin?
There was a
> problem on some parts where even though pins were 5V tolerent, if the
> pin was shared with a ADC i/p, even if the ADC was on a different
> pin, the conversion gave the wrong result. This may have been fixed,
> though.
ADC-inputs are mostly at ground (I have measured) and I exercise them
with about 2V.
But thanks for you giving me your time so far, and the others too.
--
Timo
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
Reply by Brendan Murphy●May 9, 20072007-05-09
--- In l..., tike64 wrote: >
> --- Brendan Murphy wrote:
> > The reason I said it looked wroing is that the user manual says:
> >
> >
to > > produce the clock for the A/D converter, which
should be less than or > >
> > equal to 4.5 MHz. /END QUOTE>
> >
> > One plus 0xff is 0x00 (for an 8-bit quantity), and who knows what
> > dividing by 0 would give?
>
> Good point. But most probaply the divider is implemented as an 8 bit
> counter which clears on a match with CLKDIV value. Then a value of 0xFF > ends up dividing by 0x100.
>
> But anyway, I tried with 0x0F and nothing changed.
>
> As a side note, I have noticed that the value of ADSTAT is 0x00010001 > after the conversion. This is strange because the
reset value of the
> ADINTEN register is 0x100 which should mean that the bit 0 of the
> ADSTAT could not go high. I added code to explicitly clear the ADINTEN > register but the bit 0 of ADSTAT still goes high (bit
16 stays low
> now).
>
> --
>
> Timo
Two other things I'd check:
- Check out the assembler code generated to make sure it's doing what
you think it is. In particular that code isn't optimised away or the
struct type cast does what you expect (I'd never use a struct type
cast to map to hardware registers by the way, as it's too compiler
dependent). Simplest might be to turn the optimiser off.
- Do you have any voltage more than 3.3V on any pin? There was a
problem on some parts where even though pins were 5V tolerent, if the
pin was shared with a ADC i/p, even if the ADC was on a different
pin, the conversion gave the wrong result. This may have been fixed,
though.
