--- Brendan Murphy wrote:
> Have you checked the peripheral power control
register?
Yes, I just posted my code where I set the bit 12. I also just checked
with debugger that it stays high (PCONP was 0x04287ffe)
> I think the documented default value may be incorrect
on at least
> some of the parts, though this was some time ago.
>
> If you can get it, maybe try some other code (known to work) on your
> system. Or try your own code on some other system. This should
> isolate whether the problem is h/w or s/w related.
I have other identical boards but the code behaves identically on them.
This first time I design for LPC-series so I have no known-to-work
code. Is there anyone on this list who could share his/her binary (in
source form I have seen many).
--
Timo
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
LPC2468 ADC values are always zero
Started by ●May 5, 2007
Reply by ●May 9, 20072007-05-09
Reply by ●May 9, 20072007-05-09
As a matter of interest, why are you setting AD0CR.CLKDIV to 0xff?
Looks wrong to me.
Brendan
--- In l..., tike64 wrote:
>
> --- Leon wrote:
> > You could post your ADC code, someone will probably see where you
are
> > going wrong.
>
> Ok, I inline relevant parts here:
> #include #define PINSEL_BASE_ADDR 0xE002C000
> #define PINSEL0 (*(volatile unsigned long *)(PINSEL_BASE_ADDR +
0x00))
> #define PINSEL1 (*(volatile unsigned long *)(PINSEL_BASE_ADDR +
0x04))
> #define PINSEL3 (*(volatile unsigned long *)(PINSEL_BASE_ADDR +
0x0C))
>
> #define SCB_BASE_ADDR 0xE01FC000
>
> #define PCONP (*(volatile unsigned long *)(SCB_BASE_ADDR + 0x0C4))
>
> #define AD0 (*(struct ad *)0xE0034000)
>
> struct ad {
> volatile unsigned long
> cr, gdr, pad, inten, dr[8], stat; };
>
> volatile int
> Timer; // 10ms counter
>
> int
> main(void) {
> static unsigned adreg[16], add[16];
> int adt, i;
>
> PINSEL0 = 0x4F000A54; // I have checked these
> PINSEL1 = 0x14155C05; // to keep their values
> PINSEL3 = 0xF0802080;
> PCONP |= 1 << 12;
> AD0.cr = 0x0020FF01;
> adt = Timer;
> while (1) {
> if (Timer - adt >= 0) {
> adt = Timer + 100;
>
> /* Start command for channel 0 */
> AD0.cr = 0x0120FF01;
>
> /* This is how I have also tried
> AD0.cr &= ~0x000000FF;
> AD0.cr |= 1 << 24 | 1;
> */
> /* and third variation
> AD0.cr = 0x0020FF00 | 1 << adc;
> AD0.cr = 0x0120FF00 | 1 << adc;
> */
> for (i = 0; i < 16; ++i) add[i] = ((unsigned *)&AD0)[i];
> for (i = 0; i < 16; ++i) if (adreg[i] != add[i]) {
> adreg[i] = add[i];
> printf("AD0[%02i]: %08X\n", i, adreg[i]); }
> if (add[1] & 0x80000000) {
>
> /* This was in NXP's example bundle but nothing changed
> AD0.cr &= ~0x07000000;
> */
> printf("AD0: %03i\n",
> (add[1] & 0xFFFF) * 1000 + 0x8000 >> 16); }}}}
> --
>
> Timo
>
>
>
______________________________________________________________________
______________
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
>
Looks wrong to me.
Brendan
--- In l..., tike64 wrote:
>
> --- Leon wrote:
> > You could post your ADC code, someone will probably see where you
are
> > going wrong.
>
> Ok, I inline relevant parts here:
> #include #define PINSEL_BASE_ADDR 0xE002C000
> #define PINSEL0 (*(volatile unsigned long *)(PINSEL_BASE_ADDR +
0x00))
> #define PINSEL1 (*(volatile unsigned long *)(PINSEL_BASE_ADDR +
0x04))
> #define PINSEL3 (*(volatile unsigned long *)(PINSEL_BASE_ADDR +
0x0C))
>
> #define SCB_BASE_ADDR 0xE01FC000
>
> #define PCONP (*(volatile unsigned long *)(SCB_BASE_ADDR + 0x0C4))
>
> #define AD0 (*(struct ad *)0xE0034000)
>
> struct ad {
> volatile unsigned long
> cr, gdr, pad, inten, dr[8], stat; };
>
> volatile int
> Timer; // 10ms counter
>
> int
> main(void) {
> static unsigned adreg[16], add[16];
> int adt, i;
>
> PINSEL0 = 0x4F000A54; // I have checked these
> PINSEL1 = 0x14155C05; // to keep their values
> PINSEL3 = 0xF0802080;
> PCONP |= 1 << 12;
> AD0.cr = 0x0020FF01;
> adt = Timer;
> while (1) {
> if (Timer - adt >= 0) {
> adt = Timer + 100;
>
> /* Start command for channel 0 */
> AD0.cr = 0x0120FF01;
>
> /* This is how I have also tried
> AD0.cr &= ~0x000000FF;
> AD0.cr |= 1 << 24 | 1;
> */
> /* and third variation
> AD0.cr = 0x0020FF00 | 1 << adc;
> AD0.cr = 0x0120FF00 | 1 << adc;
> */
> for (i = 0; i < 16; ++i) add[i] = ((unsigned *)&AD0)[i];
> for (i = 0; i < 16; ++i) if (adreg[i] != add[i]) {
> adreg[i] = add[i];
> printf("AD0[%02i]: %08X\n", i, adreg[i]); }
> if (add[1] & 0x80000000) {
>
> /* This was in NXP's example bundle but nothing changed
> AD0.cr &= ~0x07000000;
> */
> printf("AD0: %03i\n",
> (add[1] & 0xFFFF) * 1000 + 0x8000 >> 16); }}}}
> --
>
> Timo
>
>
>
______________________________________________________________________
______________
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
>
Reply by ●May 9, 20072007-05-09
--- tike64 wrote:
> Ok, I inline relevant parts here:
Ahh, Yahoo's interface nicely removes all indentations.
The same as an attachement.
--
Timo
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
> Ok, I inline relevant parts here:
Ahh, Yahoo's interface nicely removes all indentations.
The same as an attachement.
--
Timo
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
Reply by ●May 9, 20072007-05-09
--- In l..., tike64 wrote:
>
> --- tike64 wrote:
> > Ok, I inline relevant parts here:
>
> Ahh, Yahoo's interface nicely removes all indentations.
>
> The same as an attachement.
>
> --
>
> Timo
It also removes attachments.....
Easier to read missing indentations than missing attachments!
Brendan
>
> --- tike64 wrote:
> > Ok, I inline relevant parts here:
>
> Ahh, Yahoo's interface nicely removes all indentations.
>
> The same as an attachement.
>
> --
>
> Timo
It also removes attachments.....
Easier to read missing indentations than missing attachments!
Brendan
Reply by ●May 9, 20072007-05-09
--- Brendan Murphy wrote:
> As a matter of interest, why are you setting AD0CR.CLKDIV to 0xff?
I have tried several values from 3 (which should give 4.5MHz) upwards.
It didn't change anything. I thought that the slowest would be the
safest.
> Looks wrong to me.
Reading the UM there shouldn't be anything wrong with it but will try
another values again.
--
Timo
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid96546091
> As a matter of interest, why are you setting AD0CR.CLKDIV to 0xff?
I have tried several values from 3 (which should give 4.5MHz) upwards.
It didn't change anything. I thought that the slowest would be the
safest.
> Looks wrong to me.
Reading the UM there shouldn't be anything wrong with it but will try
another values again.
--
Timo
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid96546091
Reply by ●May 9, 20072007-05-09
--- In l..., tike64 wrote:
>
> --- Brendan Murphy wrote:
> > As a matter of interest, why are you setting AD0CR.CLKDIV to 0xff?
>
> I have tried several values from 3 (which should give 4.5MHz)
upwards.
> It didn't change anything. I thought that the slowest would be the
> safest.
>
> > Looks wrong to me.
>
> Reading the UM there shouldn't be anything wrong with it but will
try
> another values again.
>
> --
>
> Timo
>
The reason I said it looked wroing is that the user manual says:
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?
Brendan
>
> --- Brendan Murphy wrote:
> > As a matter of interest, why are you setting AD0CR.CLKDIV to 0xff?
>
> I have tried several values from 3 (which should give 4.5MHz)
upwards.
> It didn't change anything. I thought that the slowest would be the
> safest.
>
> > Looks wrong to me.
>
> Reading the UM there shouldn't be anything wrong with it but will
try
> another values again.
>
> --
>
> Timo
>
The reason I said it looked wroing is that the user manual says:
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?
Brendan
Reply by ●May 9, 20072007-05-09
--- Brendan Murphy wrote:
> The reason I said it looked wroing is that the user manual says:
>
> > 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
__________________________________________________
> The reason I said it looked wroing is that the user manual says:
>
> > 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
__________________________________________________
Reply by ●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.
Brendan
>
> --- 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.
Brendan
Reply by ●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
> 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 ●May 9, 20072007-05-09
--- 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
> > - 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
