Searching \ for '[PIC] 18F1320 A/D and Vref+' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=a%2Fd
Search entire site for: '18F1320 A/D and Vref+'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 18F1320 A/D and Vref+'
2009\03\11@043636 by Jinx

face picon face
Getting some unexpected results (and very much un-needed project
delays) trying to use the 18F1320's A/D and Vref+

The initial problem was that the A/D result was coming out a little low,
but investigating that has led to perhaps another

Vcc = 5.40V
Vref+ = 5.12V, applied to AN3/Vref+ pin
256R (4-20mA load) from AN0 to Vss

8MHz INTOSC (verified by timing tests)
TRISA.3 and .0 as inputs
ADCON1.3 and .0 as analogue
01 in VCFG<1:0>, for Vref+ and Vss
Channel0 permanently selected

Firstly, results are low. For example, an input voltage of 1.385V,
as measured at AN0 pin, should return 0x114. What is returned is
0x103, and similarly differences with other input voltages

Then next thing I notice is that Vref+ seems to be being ignored. If
it's removed from AN3 and a pull-down used, the A/D still functions
as above. If VCFG is set for Vcc and Vss, the A/D output is still
low

I've looked through the datasheet and all the errata I can find, and tried
several 18F1320 (date code 0745) straight out of the tube, but I'm still
none the wiser as to how to understand and fix this

Any suggestions ?

TIA

2009\03\11@053132 by Alan B. Pearce

face picon face
>Vcc = 5.40V

Isn't that somewhat on the high side? I would want to bring that down to
5.25 max I would think.

>Then next thing I notice is that Vref+ seems to be being ignored.
>If it's removed from AN3 and a pull-down used, the A/D still
>functions as above. If VCFG is set for Vcc and Vss, the A/D output
>is still low

Could this be a result of the Vcc listed above? I haven't checked the
datasheet for max operating voltage, but remembering some of the funnies you
and/or Russell have mentioned in the past when taking pins above Vcc, I
wonder if something similar is happening with too great a Vcc.

2009\03\11@063625 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
> Of Alan B. Pearce
> Sent: 11 March 2009 09:32
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] 18F1320 A/D and Vref+
>
> >Vcc = 5.40V
>
> Isn't that somewhat on the high side? I would want to bring that down
to
> 5.25 max I would think.
>
> >Then next thing I notice is that Vref+ seems to be being ignored.
> >If it's removed from AN3 and a pull-down used, the A/D still
> >functions as above. If VCFG is set for Vcc and Vss, the A/D output
> >is still low
>
> Could this be a result of the Vcc listed above? I haven't checked the
> datasheet for max operating voltage, but remembering some of the
funnies
> you
> and/or Russell have mentioned in the past when taking pins above Vcc,
I
> wonder if something similar is happening with too great a Vcc.

The 18F1320 voltage range is 2.0-5.5 volts, so this should be fine.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\11@064007 by Jinx

face picon face
> >Vcc = 5.40V

> wonder if something similar is happening with too great a Vcc.

5.4V is the highest Vcc will get in this app (more often it's 5.3V due
to loading by several circuits), and it is under Microchip spec of 5.5V
max

One other point re the observations. Both Vcc and Vref+ are stable
and glitch-free with little noise, just a few mV, at all times

I'll try 5V Vcc and say 4V Vref+ to see what happens

2009\03\11@064359 by Richard Seriani

picon face

----- Original Message -----
From: "Jinx" <joecolquittspamKILLspamclear.net.nz>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam.....mit.edu>
Sent: Wednesday, March 11, 2009 5:35 AM
Subject: [PIC] 18F1320 A/D and Vref+


{Quote hidden}

Is Vref- tied to RA2?



2009\03\11@070627 by Jinx

face picon face
> I'll try 5V Vcc and say 4V Vref+ to see what happens

Same result

Vcc = 4.982V, input = 1.384V and Vref+ = 3.735V, A/D result = 285

This result is representative of the reference being Vcc, not Vref+,
even though Vref+ is selected in ADCON1. Obviously AN0 and the
A/D module must be set up correctly to some extent to get that result,
so I'm left with the puzzle of why Vref+ is not getting through to the
converter. I would have expected a result of 379

2009\03\11@070721 by Jinx

face picon face

> Is Vref- tied to RA2?

No, Vref- is Vss. RA2 is set as a digital output

2009\03\11@075030 by olin piclist

face picon face
Jinx wrote:
> Vcc = 5.40V
> Vref+ = 5.12V, applied to AN3/Vref+ pin
> 256R (4-20mA load) from AN0 to Vss
>
> 8MHz INTOSC (verified by timing tests)
> TRISA.3 and .0 as inputs
> ADCON1.3 and .0 as analogue
> 01 in VCFG<1:0>, for Vref+ and Vss
> Channel0 permanently selected
>
> Firstly, results are low. For example, an input voltage of 1.385V,
> as measured at AN0 pin, should return 0x114. What is returned is
> 0x103, and similarly differences with other input voltages
>
> Then next thing I notice is that Vref+ seems to be being ignored.

Your numbers above are consistant with that too.  You are getting 103h =
259.  1023 * 1.385 / 5.40 = 262.  Your reading is only 1.15% lower than
that.

> I've looked through the datasheet and all the errata I can find, and
> tried several 18F1320 (date code 0745) straight out of the tube, but
> I'm still none the wiser as to how to understand and fix this

I've never tried to use Vref+ on a 18F1320.  I've had bad experiences with
that chip myself and have heard bad stories from others too.  Those were a
few years ago so that probably is behind us.  Make sure you have a recent
date code or silicon revision.

Otherwise, be really really sure you enabled the external Vref in the A/D
config.  Read back the configuration register at run time to be sure.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\11@075329 by Alan B. Pearce

face picon face
>> Is Vref- tied to RA2?
>
>No, Vref- is Vss. RA2 is set as a digital output

Presumably you have attended to the required low source impedance for Vref,
but that wouldn't explain why it gives the same number when you remove Vref
...

Are really really really sure VCFG1:0 is 0x01 instead of 0x00 ... ???

What happens if your code tries to measure the voltage on AN3 using the A/D
... ?

2009\03\11@171451 by Jinx

face picon face
> Presumably you have attended to the required low source impedance
> for Vref

It's derived from a 78L05, which isn't ideal but it is stable enough and
should be lo-Z. I've looked at Vref+ closely and it doesn't glitch. But
if it's not actually being drawn on by the A/D it wouldn't would it

> Are really really really sure VCFG1:0 is 0x01 instead of 0x00 ... ???

That's what I'm wondering

I've been here before with wonky SFR initialisation. On at least one
other occassion, after hours and hours of doesn't-make-sense staring
and sighing, changing the order of loading values into SFRs made the
code work. I wouldn't be surprised if that turns out to be the case this
time. The last time I could find no documentation beforehand, and alerted
MC to it after finding the solution



2009\03\11@175647 by Marcel Duchamp

picon face
Jinx wrote:
{Quote hidden}

Can you do conversions, change the Vref, do more conversions and then
compare? The answers should show this one up immediately.  No change, no
actual use of your external Vref.

2009\03\11@190753 by Jinx

face picon face
> Are really really really sure VCFG1:0 is 0x01 instead of 0x00 ... ???

Using an external RAM capture, after initialisation and a few conversions -

ADCON0 = 0x41 = b'01000001' => VCFG = 01 and ADON = 1
ADCON1 = 0x76 = b'01110110' => AN3 and AN0 as analogue
ADCON2 = 0xBB = b'10111011' => right-justified, ACQ and clock

TRISA = b'00001001' = AN3 and AN0 as i/p

CONFIG MCLRE = ON and TRISA,5 is set (but doesn't appear when
TRISA is copied to RAM. Hmmm. Although reset works)

In code

        movlw   b'00101001'
        movwf   trisa

        movlw   b'00000000'
;                  00000000    LCD
        movwf   trisb

        movlw   b'01000001'
;                  01          Vref+ Vss
;                    x
;                     000      channel 0 selected
;                        0     go/done
;                         1    A/D module on
        movwf   adcon0

        movlw   b'11110110'
;                  ----0--0    AN3,0 analogue i/p
        movwf   adcon1

        movlw   b'10111011'
;                  1           right-justify result
;                   x
;                    111       ACQ
;                       011    clock
        movwf   adcon2

> Can you do conversions, change the Vref, do more conversions and
> then compare? The answers should show this one up immediately. No
> change, no actual use of your external Vref

No matter what I do on AN3 it makes no difference to the A/D result.
It always comes back as referred to 5V Vcc. With Vref+ currently set
around 3.8V, result should be about 380, not 280

I've tried dropping from 8MHz INTOSC to 4MHz, because I've had
problems on the F88 with 8MHz, but that made no difference

2009\03\11@202145 by Jinx

face picon face
> Can you do conversions, change the Vref, do more conversions and
> then compare?

Varying Vcc between 4.5 and 5.5, with an i/p voltage derived from Vcc,
produces the same A/D result, showing that they all track together

Pretty much out of ideas now. If I have actually set up the A/D correctly
and Vref+ isn't accessible then I'll just have to use Vcc of 5.12V, which
is a major pain and not where I want to be

It seems to me that at least one switch VCFG controls doesn't work. I
can try a Vref- on AN2, see if that makes a difference

2009\03\11@212413 by Jinx

face picon face
> Is Vref- tied to RA2?

I've now tried VCFG = 11, with 0.6V on Vref- and 3.7V on
Vref+, no change. Result is still referenced to Vcc. Also an
8MHz crystal instead of INTOSC, no change. So it looks like
a ticket to Microchip unless I or someone sees something so
blindingly obvious I overlooked it

2009\03\12@061415 by Andrew Burchill

picon face
Hi Jinx
I have a question...
can you confirm your intentions for the ADCON2 reg
specifically  the clock source?

On Wed, Mar 11, 2009 at 6:06 PM, Jinx <EraseMEjoecolquittspam_OUTspamTakeThisOuTclear.net.nz> wrote:

> > Are really really really sure VCFG1:0 is 0x01 instead of 0x00 ... ???
>
> Using an external RAM capture, after initialisation and a few conversions -
>
> ADCON0 = 0x41 = b'01000001' => VCFG = 01 and ADON = 1
> ADCON1 = 0x76 = b'01110110' => AN3 and AN0 as analogue
> ADCON2 = 0xBB = b'10111011' => right-justified, ACQ and clock
>

it seems from my limited understanding of the d/s you have set the Tad as
011
this is supposed to source the AD clock from INTRC, ok as long as the device
frequency is not above 1MHz, but a note at 17.4 and table 17.1 of 39605F
suggest this is only correct while using sleep.

regards
--
...AB

2009\03\12@072944 by Jinx

face picon face
> can you confirm your intentions for the ADCON2 reg
> specifically  the clock source?

The example posted (b'10111011') was just a last desperate attempt
to get any sort of meaningful conversion from a breadboarded PIC

This is what I'm trying now with Vcc = 5.12V in the actual unit. Results
are exactly what I expect, to within a bit

        movlw   b'10110110'
;                  1           right-justified
;                   x
;                    110       acquisition, 16 Tad
;                       110    conversion clock, 64 Fosc
        movwf   adcon2

Now that it's working I've got somewhere to start from, wrt
parameters 130 (A/D clock period) and 132 (acquisition time)

I've sent a ticket to Microchip support re the Vref problem

2009\03\12@081632 by olin piclist

face picon face
Jinx wrote:
> I've now tried VCFG = 11, with 0.6V on Vref- and 3.7V on
> Vref+, no change. Result is still referenced to Vcc. Also an
> 8MHz crystal instead of INTOSC, no change. So it looks like
> a ticket to Microchip unless I or someone sees something so
> blindingly obvious I overlooked it

I know you think you're setting the bit to use Vref+.  How do you know there
isn't a bug that stomps on it later.  As I originally suggested, I'd check
the critical bit or two regularly during normal operation after
initialization and write the values out somehow.  This could be out the
serial port, or wiggling a pin, or whatever.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\12@161738 by Jinx

face picon face
> I know you think you're setting the bit to use Vref+.  How do you
> know there isn't a bug that stomps on it later

You might have missed a post, I've looked into that

"Using an external RAM capture, after initialisation and a few conversions -

ADCON0 = 0x41 = b'01000001' => VCFG = 01 and ADON = 1"

I even included a BSF ADCON0,6 in the loop that samples and displays


2009\03\16@183708 by Jinx

face picon face
So far the response from Microchip Support is that what I've done
should work if Vcc >= Vref+ and voltages are in spec, which it is
and they are

Leaving me feeling a bit insecure. Because I find it hard to believe
that no one before me has tried and failed to use Vref+ on this PIC

Then again, I thought the same about I2C until Microchip admitted to
a SSPIF silicon bug on the 16F88 running at 8MHz INTOSC, after
me pulling the chip and code apart for 2 weeks. And I note that that
bug is not yet (3 years on) in the F88 errata, even the specific SSP
errata sheet

Unfortunately in the 18F there isn't the wide choice in the low I/O range
as there is with the 16F, so I'll stick with the 18F1320 and modify the
circuit for 5.12V Vcc, unless MS can come up with something

2009\03\17@081940 by olin piclist

face picon face
Jinx wrote:
> Leaving me feeling a bit insecure. Because I find it hard to believe
> that no one before me has tried and failed to use Vref+ on this PIC

Maybe.  Keep in mind this PIC has lot of bad history and most people
deliberately avoid it.  Then using a separate Vref is a further small
subset.  Generally using Vdd is good enough when a 10 bit A/D is good
enough.  I probably used Vref+ a few times out of 100 projects, but right
now I can't even remember a specific project where I did.

Are you really sure you can't use a 16F88?  That's the mainstream part for
this footprint with a A/D.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\17@112935 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: piclist-bouncesspamspam_OUTmit.edu [@spam@piclist-bouncesKILLspamspammit.edu] On
Behalf
{Quote hidden}

Joe,

If you stick a scope on the Vref+ pin (with reference connected) do you
get a nice stable voltage with the PIC running?

Is there any chance that something in your code is accidently turning
RA3 into an output and driving the reference voltage up?

Cheers

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\17@170317 by Jinx

face picon face
> Are you really sure you can't use a 16F88?  That's the mainstream
> part for this footprint with a A/D

I did actually start out with the F88. This is an SMS processing device
with a central 4550 and several smaller PICs controlling sub-sections.
The problem that quickly became apparent was that the single FSR of
the F88 was not enough for all the string manipulations needed. Code
is considerably simpler and smaller with the 1320's three FSRs (LFSR,
POSTINC etc), instruction set and no banking

The deal with Vref is because the plan was to not use Vcc as reference
for external inputs/sensors. The 5.3V Vcc rail could be a bit rough, so
many things using it, and Vref more accurate


2009\03\17@170317 by Jinx

face picon face
> If you stick a scope on the Vref+ pin (with reference connected) do
> you get a nice stable voltage with the PIC running?

Yes

> Is there any chance that something in your code is accidently turning
> RA3 into an output and driving the reference voltage up?

Analogue voltages on pins are OK

Based on the simplicity of the test code and the captured SFR values
after conversions, I'd say the TRISA and the ADCON registers are
accessed (explicitly) only once. My belief is that the switches controlled
by VCFG aren't working

When I have some spare time I will go back and have another look at
it. Maybe I've missed something, I don't know. For now, busy playing
catch up

2009\03\17@202417 by Jinx

face picon face
> Keep in mind this PIC has lot of bad history and most people
> deliberately avoid it

So far this is the only problem. Which is annoying enough, no doubt,
but otherwise the 1320 seems to work OK

> Then using a separate Vref is a further small subset

If it proves to be the case that I'm right, I'm left wondering what
tests Microchip actually do on new silicon. Some bugs are picked
up (by whom ?) and put in errata sheets, yet other confirmed bugs
aren't. I know you've mentioned this previously

My discussions with Microchip Support are ongoing. We've covered
all the obvious. Pin setting, voltage measurements etc. I've re-read
the datasheet for any "Don't do this if ...." type of thing but nothing
jumps out. Hopefully it will be passed to an engineer to have a look
at on a real chip

Or if anyone here feels keen enough to try and make Vref+ work
on a 1320 they might have lying around ...... If I'm wrong, that's fine.
Embarrassing perhaps, but I'll get over it

2009\03\18@022347 by Rikard Bosnjakovic

picon face
On Wed, Mar 18, 2009 at 02:22, Jinx <KILLspamjoecolquittKILLspamspamclear.net.nz> wrote:

> Or if anyone here feels keen enough to try and make Vref+ work
> on a 1320 they might have lying around ...... If I'm wrong, that's fine.
> Embarrassing perhaps, but I'll get over it

I had no plans for today so I was just about to do this. Unfortunately
it seems that I'm only having 1330's and no 1320's, so I can't perform
the test.


--
- Rikard - http://bos.hack.org/cv/

2009\03\18@030155 by William \Chops\ Westfield

face picon face
>> Or if anyone here feels keen enough to try and make Vref+ work
>> on a 1320 they might have lying around ...... If I'm wrong, that's  
>> fine.
>> Embarrassing perhaps, but I'll get over it

I wonder if it's something like an incorrect definition of one of the  
register or bit definitions in the relevant include files (or even  
maybe the documentation as well.)

BillW

2009\03\18@034607 by Jinx

face picon face
RB > I had no plans for today so I was just about to do this.
RB> Unfortunately it seems that I'm only having 1330's and no
RB> 1320's, so I can't perform the test

Thanks for thinking about it anyway

WCW > I wonder if it's something like an incorrect definition of one of
WCW > the register or bit definitions in the relevant include files

Good thought. I've checked in the Program Memory window and
the three MOVLW/MOVWF instructions have the correct values
and destinations

WCW > (or even maybe the documentation as well.)

MPLAB and the .inc file match the datasheet

2009\03\18@053748 by Alan B. Pearce

face picon face
>MPLAB and the .inc file match the datasheet

I would suggest that you post your problem to the Microchip Forum, if you
haven't already done so, with your simple test code. I have a suspicion that
problems posted there may get seen by the behind-the-scenes people more
readily than something just sent to support.

Not something I have definite experience with, just a hunch from answers I
have seen, where it is evident that a posted problem has gone deep into the
organisation.

2009\03\18@064343 by Jinx

face picon face
> I would suggest that you post your problem to the Microchip Forum,
> if you haven't already done so, with your simple test code

Yeah, did that after the first response from Support. Couple of dozen
hits but no replies


'[PIC] 18F1320 A/D and Vref+'
2009\04\06@194735 by Jinx
face picon face
Just an update -

Going around in circles with Microchip Support. Initial responses were
quite sensible, but later ones are clutching at straws/stabbing in the dark
and straying from the issue

{Quote hidden}

!!!!!!!

Which is what I've been doing all along and told them several times. It's
how I found out pin voltages weren't converting properly (4% low)

> Other than those considerations, I'm not seeing anything obviously
> wrong with the design

I've asked if, after a month of me repeating myself and them saying I'm
not doing anything wrong, it's time someone at Microchip got a chip out
and just tried it

It seems to me I'm looking at a re-design with another micro. 18F1330
perhaps. I can modify a couple of functions to use the comparators as
it happens

2009\04\09@104723 by Bob Axtell

face picon face
I've had some troubles with the PIC A/D converters and I have found
that the ICE2K emulator has enormous (almost unusable) errors, whereas
the actual devices run closely. So I check the A/D converters using an
ICD2.

To reduce the input impedance, place a CAP at the converter input. I
try to make it as large as possible for the task needed; for example,
if I am trying to just divide an external voltage, I use a 0.1uF
(10nF), but if I am reading a switch array (my favorite way to read
switches is by using an A/D, convert it every 10mS, then see into what
window the result fits) I only use the 200pF of the varistor used at
the input (nothing extra). The advantage of reading switches this way
is to protect the uP from ESD, and it is CHEAP, too.

The heavy cap at the input provides the current drained by the capture
FET switch, otherwise the conversion almost always reads low if the
impedance is high. For other
applications, I keep the impedance below 2K.

--Bob A

On 4/6/09, Jinx <RemoveMEjoecolquittTakeThisOuTspamclear.net.nz> wrote:
{Quote hidden}

> -

2009\04\09@182608 by Jinx

face picon face

> To reduce the input impedance, place a CAP at the converter input

Bob, hi. The test I used is with a 500R pot, which is quite a bit lower
than maximum i/p impedance. The other indicator that the PICs (from
the batches I have) are faulty is that measuring AN3 / Vref also returns
a low - and calculable - result, and Vref is a regulator with 3.3uF on
the o/p

Still in discussion with Microchip. Lastly was the response to them along
the lines of  'just because you don't know about a problem doesn't mean
there isn't one'. I'm sending them a couple of my chips

> (my favorite way to read switches is by using an A/D, convert it every
> 10mS, then see into what window the result fits)

I repaired my nephew's Korg effects pedal a while back and was delighted
to find that the two 9-way rotary 'switches' are in fact pots with detentes

2009\04\10@140336 by Bob Axtell

face picon face
Hi, Jinx. I'm surprised that the error is that bad on production PICs. But I am
not using either reference pin, just GND and VDD. Golly, a 500-ohm POT
should be VERY close, except that sometimes pots are discovered with
bad non-linearities (usually as a result of overstressing).

As I said, we even bought another POD for the ICE2K (DVA16PQ441) for
the PIC16F877A.. The 2nd pod was just as bad as the first. So we check
analog functions with the ICD2.

--Bob

On Thu, Apr 9, 2009 at 3:25 PM, Jinx <spamBeGonejoecolquittspamBeGonespamclear.net.nz> wrote:
{Quote hidden}

>

2009\04\10@192723 by Jinx

face picon face
> I'm surprised that the error is that bad on production PICs

Bob, I'm sure this isn't a conversion error. It seems to me that the
reference switches aren't working. For whatever reason, mine or
Microchip

I managed to get hold of 2 other batch codes and tried them on the
breadboard. I got the same results as the batch I just bought

However, and I find this very intriguing, just once I saw 1023 come
up. And turning the pot did make the display vary between 0 and 1023.
I have not seen that before in many many dozens of tests. But this chip
did it only once and I have not been able to make it do it again. When
I reset the PIC, 988 was once more the maximum reading I could get

In some way I wish I hadn't seen it because it raises more questions

One of three things could have happened (assuming that the PIC has
been coded correctly)

(1) somehow, and I can't imagine how, Vcc got onto Vref+. Not
impossible, but IMHO very unlikely. Externally anyway. The wiring is
pretty tidy

(2) the internal switches worked and then broke

(3) something inside the chip was activated by something in the power-up.

MCLR has RC, PWRT is on, I don't see anything unusual on a scope or
analyser

Given my experience with undocumented-things-like-that, my guess is (3),
particularly as it stopped working 'properly' after an MCLR reset

2009\04\10@201116 by Marcel Duchamp

picon face
Jinx wrote:
> However, and I find this very intriguing, just once I saw 1023 come
> up. And turning the pot did make the display vary between 0 and 1023.
> I have not seen that before in many many dozens of tests. But this chip
> did it only once and I have not been able to make it do it again. When
> I reset the PIC, 988 was once more the maximum reading I could get
>
> (1) somehow, and I can't imagine how, Vcc got onto Vref+. Not
> impossible, but IMHO very unlikely. Externally anyway. The wiring is
> pretty tidy
>
> (2) the internal switches worked and then broke
>
> (3) something inside the chip was activated by something in the power-up.
>
> MCLR has RC, PWRT is on, I don't see anything unusual on a scope or
> analyser
>
> Given my experience with undocumented-things-like-that, my guess is (3),
> particularly as it stopped working 'properly' after an MCLR reset

Maybe the device is sensitive to the way that either the power supply
comes up or the way the reset is released or both.  I had a problem a
few years ago where a board occasionally would hang on power up.  No
amount of manually fiddling with it could expose it. (customers could
find it though!) I made a power up PFET switch that was controlled by a
pic and would:
a) power up the board
b) look for a string from the 232 port
c) tally up any bad starts
d) over and over and over.

It would vary the amount of time between power up and releasing the
reset as well as vary the rate of power rise.  Eventually a set of data
came up (after running all night and on weekends) that showed the
criteria that seemed to provoke it.  The problem was totally different
from your a/d problem but it was due to some combination of power supply
and reset.  I do not have any data or information on any of it but our
problem was not due to the pic but the way the board was wired. In your
case, it may well be the pic that is sensitive to some combination of
power supply/reset.

Something else just came to mind - try repeated startup with the input
a/d voltage set so you can immediately see the resulting counts and know
if it is right or not.  Then while it cranks away, try freeze spray
and/or heating the pic.

Hope you find it!

2009\04\10@224330 by Jinx

face picon face
> Hope you find it!

I didn't find a cause, but Bill Bross did off-list. And it's so simple I
could, and should, cringe

Unfortunately, some macros were copied from a pretty old project
and I didn't alter them

Who wants to play "Spot the dufus" ?

adch0    macro                ;select ADC channel 0
        movlw   b'00000001'
        movwf   adcon0
        endm

        movlw   b'01000001'
;                  01          Vref+ Vss
;                    x
;                     000      channel 0 selected
;                        0     go/done
;                         1    A/D module on
        movwf   adcon0

No one who saw the source, and very much especially me, made the
ADCON0 connection. Not that I'm apportioning blame to anyone but
myself

The previous project did not use Vref+ and so '00xxxxxx' in the macro
has no effect. Nowadays I would use specific selection bits, but in that
older project I didn't

So I quite readily put my hands up to this one, as I said I would very
early in the thread. A mistake I should have picked up on but with the
macro so far removed in the text from the code I completely understand
why I missed it. Even trying to stick to my principle of 'justify
everything'
it still took someone else's eyes to find it. And I thank Bill for his keen
ones

Luckily I'm not as shame-faced as I could have been. Despite my
concerns about Microchip's silicon and documentation, I did manage to
resist the temptation to blame it conclusively on the chip. Whilst
programming chips this week to go back to Microchip I got hold of 3
other batch samples and they all showed the same 'fault'. Which, in all
honesty, really didn't sound right. That did get me thinking about the
circuit but not the code, which I doubt I would have gone over again

So there ya go

You know the old saying "When you point at someone, there are
three fingers pointing back at yourself". How uncomfortably true that
can be sometimes

Thanks to all who took an interest

2009\04\10@225324 by Jinx

face picon face
BTW, Bill, if you're reading this, my off-list replies to you have been
bouncing back for a couple of days

Thanks again

===============

Your message cannot be delivered to the following recipients:

 Recipient address: wbross@
 Reason: Rejection greeting returned by server.
 Diagnostic code: smtp;554 5.7.1 - ERROR: Mail refused -
 

2009\04\10@231901 by Marcel Duchamp

picon face
All's well that ends well.  Good on you and Bill!

Jinx wrote:
>> Hope you find it!
>
> I didn't find a cause, but Bill Bross did off-list. And it's so simple I
> could, and should, cringe

2009\04\10@234008 by Jinx

face picon face
>> However, and I find this very intriguing, just once I saw
>> 1023 come up

> Maybe the device is sensitive to the way that either the power supply

Marcel, I now find what I saw intriguing for a different reason

The 1023 came up with the old code, and it shouldn't have. With the
code settings as was, 988 was in fact the correct FSD result all along.
So what happened during power-up that one time to make the PIC
set VCFG to 01 (presumably) instead of 00 ?

2009\04\11@074610 by William Bross

picon face


Jinx wrote:

{Quote hidden}

I told Jinx off-list that when he published his problem, it was two days
after I just sent out my first F1320 based board design to the pcb
vendor (a lot of boards).  I was on pins and needles until I verified my
little a/d worked, which had its own set of problems.  Just to get some
of the 'heat' off Jinx for this, I'll admit to my dufus moment with my
board.  I put a MCP601 op amp on it for signal conditioning my a/d
input.  I laid it out for the 'T' version which has VDD and VSS
backwards from the normal version.  My junior engineer had some LMV431
or something like that for his board he was working on.  I forgot to
order my MCP parts and grabbed one of his amps.  Hey, 5 pin SOT op amps
all have the same pin out right???  WRONG!!!  My board registered about
an amp of current draw for say......30 seconds before it went up in
smoke.  That's a mistake I won't make again.

Anyway, my boards a/d worked just fine whether it was with internal or
external Vref.  But when I built up his circuit and used his code, I got
results as he published them.  It didn't take long to sort out the problem.

Having a second (or about 2K ) set of eyes from the list is good backup
to have whether you are a lone consultant or just a hobbyist, even if
you find yourself a little  embarassed occasionally.

BTW, I got the message about bouncing messages so I'll look into that.

Bill

2009\04\11@091334 by olin piclist

face picon face
Jinx wrote:
> Unfortunately, some macros were copied from a pretty old project
> and I didn't alter them

Stuff like that happens, but I thought you had read back the A/D control
registers and verified they were right.  At least this was a suggestion made
very early on and I thought you had followed it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\04\11@094137 by Jinx

face picon face
> but I thought you had read back the A/D control registers and
> verified they were right.  At least this was a suggestion made
> very early on and I thought you had followed it.

You're absolutely right Olin. I'd forgotten that. The A/D registers
did indeed read back as I thought they should have been set. It's
what led me to conclude that the VCFG switches weren't working

Wow. That's a real mystery. How on earth do I explain it ?

> "Using an external RAM capture, after initialisation and a few
> conversions -
>
> ADCON0 = 0x41 = b'01000001' => VCFG = 01 and ADON = 1"

2009\04\11@180144 by William \Chops\ Westfield

face picon face

On Apr 11, 2009, at 6:40 AM, Jinx wrote:

>> but I thought you had read back the A/D control registers and
>> verified they were right.  At least this was a suggestion made
>> very early on and I thought you had followed it.
>
> You're absolutely right Olin. I'd forgotten that. The A/D registers
> did indeed read back as I thought they should have been set.

You probably read them back after you initialized the A-D converter,
while your macro error caused the relevant bits to be reset immediately
before you actually read the values:
       init: movlf ADCON0, (bits)
        check: read and print ADCON0
       actualcode: ad0sel  ; errant macro resets bits.

BillW

2009\04\11@215627 by Jinx

face picon face
>> You're absolutely right Olin. I'd forgotten that. The A/D registers
>> did indeed read back as I thought they should have been set.
>
> You probably read them back after you initialized the A-D converter,
> while your macro error caused the relevant bits to be reset immediately
> before you actually read the values:

Bill, pretty sure that's what must have happened. Unfortunately that part
of the file had been edited, but I just re-wrote the display loop and put an
XOR in it to turn ADCON0,6 off and on. The result flicks between 989
(Vref = Vcc) and 1023 (Vref = Vref+)

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...