PIC18F87K22 ADC

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

What happens if you run a fairly simple program like this ? Try it.

beaker404 · Joined: 24 Jul 2012 Posts: 163

I get around a 0297 HEX.
that comes out to 663 decimal and it responds to temperature change.

?????????????

Fuses?

could a fuse be messing with my INT_EXT as well? done an INT_EXT a million times and it is not working either.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I have to go out for a few hours. Look at the .LST file. Look for differences.
If you don't find anything, I'll compare them when I get back.

beaker404 · Joined: 24 Jul 2012 Posts: 163

here is my lst

and here is the small program that works

[/list]

temtronic · Posted: Thu Apr 25, 2019 2:55 pm

OK, so I scrolled through your listing ,a couple of times and some glaring problems...

The one BIG one is printing inside an ISR. That is a BIG 'nono' ! ISR MUST be small, compact and FAST. All prints are sloooooooow and need to be avoided within all ISRs.

You NEED to run PCM P's test program NOT your code. it's too full of things that can cause problems. You must minimize code to JUST 'read the ADC,print,delay, doitall again'. The raw data from the temperature sensor should be +-1 or 3 bits.

There is a lot of potential hardware problems. Long ,noisy wires from sensor to ADC, Noisy Vref,I see you're using VDD AS Vref...bad,bad,bad. While you can get away with it for an 8 bit ADC, you NEED a precision, stable source for Vref for 10,12,16 bit ADCs. Proper attention to bypass caps, PCB layout, etc. Analog can be quite 'challenging' to get right. 2/3 of my lifetime ago, I designed 32 channel, 16 bit mass spectrometer data acquistion systems...so I'm familiar with ADCs and noise. Best I could get was +-3 bits.

Jay

beaker404 · Joined: 24 Jul 2012 Posts: 163

something definitely going on here, patched in my INT_EXT code into the small test program that the ADC works in, and it works too!!! INT_EXT does not work in the original .C file that is having the ADC problems today.

corrupt file? we use onedrive here and it always wants to make MPLAB reload a version of a file randomly.

If the file is corrupt. how is the best way to recover/ keep this from happening? I have cut and pasted into a blank file, and it still does not work.

I sure hope PCM is able to find something in the LST files that is preventable and my error and not a corrupted file from who knows what.

I await the findings.

beaker404 · Joined: 24 Jul 2012 Posts: 163

well, may never know what really happened here.
I noticed that the .C file in my MPLAB project was being taken from our ONEDRIVE not my local folder that had the rest of my project in it.
This particular file was very out of date and did not call my init_hardware routine.
so, I made sure the local .C file was being opened and cut and paste starting with PCM's basic ADC program. rebuilt the rest of the file to include all of my code, testing at each step. two hours later, it all works. ADC, INT_EXT and INT_RDA now I am back where I was 11 hours ago and do not know how this happened or what really to do to keep it from happening again. I did pause the sync of ONEDRIVE for 24 hrs.

Comments? PCM, will be interested if you see anything in the LST files besides the init_hardware not being called in the version I posted.

perplexed to say the least.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

How about using ExamDiff to compare the two versions of source code ?

To find the differences between your new code and your old code:

1. Download ExamDiff from: https://www.prestosoft.com/edp_examdiff.asp
2. Run Examdiff and select those two files to compare.
3. Examdiff will load both and show differences highlighted in yellow.
You can go to the View menu and have it show differences only, if you want.

Look at the differences and locate the lines causing the problem.

beaker404 · Joined: 24 Jul 2012 Posts: 163

our IT will not allow software like that. is there an online version for comparing?

beaker404 · Joined: 24 Jul 2012 Posts: 163

found and ran diffnow. powered by examdiff.
lots of differences but one that stands out to me at least is
the first line in the file that does not work is

0000: GOTO 0568

and the first line in the file that does work is

0000: GOTO 00A0

the one that does not work has the following assembler that is prior to any instruction:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

That's the CCS interrupt dispatcher code. You will get that code
generated if you have #int_ext and #int_rda in your program.
For example, the program below will generate that code:

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

Yes, so there is obviously an enormous difference between the 'running' and
'non running' code, in that the later is using interrupts, and the former is
not.
Something you are doing in the interrupt based code is causing your issue.
You need to look at what you are doing in the interrupts. What triggers them?
What you are doing in the interrupts?. For example, INT_RDA, implies at
least one character has been received, and _requires_ your 'handler' to
read that character. If it doesn't, the interrupt cannot be cleared (well actually
it can be cleared, but will reset on the very next instruction). So if INT_RDA
is enabled and the 'handler' doesn't read the character, it'll be called
permanently, and stop the code working.....