 |
 |
| View previous topic :: View next topic |
| Author |
Message |
2xhp
Joined: 14 Jan 2019
Posts: 39
|
| ADC on a dspic |
 Posted: Tue Jan 19, 2021 4:51 pm |
 |
|
Hi,
I'm working with a processor I haven't used previously (dspic33EP64GS804). I'm having a bit of grief getting the ADC to work. I've looked through the forum and found a couple tips, but none of them have solved the issue. I have voltages being fed to 4 pins (all sensors and all reading close to half the 3.3 rail voltage). However, all I get out of read_adc() is 0x01 or 0x02 from any of the four channels (tested separately).
Compiler is PCD 5.099.
Here's the pared-back program. Although CAN communications are working, I've removed them and am relaying the ADC reading in a way I can read it using an o-scope. The 0x01 and 0x02 readings I was getting over CAN are being reflected on the high pulses using the o-scope (that is, I'm getting the same readings either way).
| Code: |
#include <33EP64GS804.h>
#device ADC=12
#fuses NOPROTECT, NOWDT
#fuses PR_PLL
#fuses XT
#fuses ICSP2
#FUSES CKSNOFSM
#use delay(clock=40M, crystal=10M)
void main() {
int16 the_reading;
// ADC channels 4, 8, 10, and 17 are being used
setup_adc_ports( sAN4 | sAN8 | sAN10 | sAN17, VSS_VDD );
setup_adc(ADC_CLOCK_SYSTEM | ADC_CLOCK_DIV_1 | ADC_SHARED_CLOCK_DIV_2 | ADC_SHARED_TAD_MUL_33 | ADC_ENABLE_SHARED_CORE);
set_adc_channel(4);
while(1) {
the_reading = read_adc();
output_high(PIN_C5);
delay_us(the_reading);
output_low(PIN_C5);
delay_us(the_reading);
}
}
|
And the list file:
CCS PCD C Compiler, Version 5.099, xxxxx 19-Jan-21 15:40
Filename: C:\temp\test.lst
ROM used: 1246 bytes (3%)
Largest free fragment is 43682
RAM used: 131 (2%) at main() level
131 (2%) worst case
Stack used: 2 locations
Stack size: 128
*
0000: GOTO 410
.................... #include <33EP64GS804.h>
.................... //////////// Standard Header file for the DSPIC33EP64GS804 device ////////////////
.................... ///////////////////////////////////////////////////////////////////////////
.................... //// (C) Copyright 1996, 2020 Custom Computer Services ////
.................... //// This source code may only be used by licensed users of the CCS C ////
.................... //// compiler. This source code may only be distributed to other ////
.................... //// licensed users of the CCS C compiler. No other use, reproduction ////
.................... //// or distribution is permitted without written permission. ////
.................... //// Derivative programs created using this software in object code ////
.................... //// form are not restricted in any way. ////
.................... ///////////////////////////////////////////////////////////////////////////
.................... #device DSPIC33EP64GS804
....................
.................... #list
....................
.................... #device ADC=12
....................
.................... #fuses NOPROTECT, NOWDT
.................... #fuses PR_PLL
.................... #fuses XT
.................... #fuses ICSP2
.................... #FUSES CKSNOFSM
....................
.................... #use delay(clock=40M, crystal=10M)
*
0400: CP0 W0
0402: BTSC.B 42.1
0404: BRA 40E
0406: REPEAT #F
0408: NOP
040A: DEC W0,W0
040C: BRA NZ,406
040E: RETURN
....................
.................... void main() {
0410: MOV #2F80,W15
0412: MOV #2FFF,W0
0414: MOV W0,20
0416: NOP
0418: BSET.B 8C1.7
041A: MOV #1E,W4
041C: MOV W4,746
041E: MOV #40,W4
0420: MOV W4,744
0422: DISI #E
0424: MOV #103,W0
0426: MOV #743,W1
0428: MOV #78,W2
042A: MOV #9A,W3
042C: MOV.B W2L,[W1]
042E: MOV.B W3L,[W1]
0430: MOV.B W0L,743
0432: LSR W0,#8,W0
0434: MOV #742,W1
0436: MOV #46,W2
0438: MOV #57,W3
043A: MOV.B W2L,[W1]
043C: MOV.B W3L,[W1]
043E: MOV.B W0L,[W1]
0440: CLR E0E
0442: CLR E1E
0444: CLR E2E
....................
.................... int16 the_reading;
....................
.................... // ADC channels 4, 8, 10, and 17 are being used
.................... setup_adc_ports( sAN17 );// | sAN8 | sAN10 | sAN17, VSS_VDD );
0446: CLR E0E
0448: CLR E1E
044A: MOV #40,W4
044C: MOV W4,E2E
044E: MOV #1FFF,W0
0450: AND 308
.................... setup_adc(ADC_CLOCK_SYSTEM | ADC_CLOCK_DIV_1 | ADC_SHARED_CLOCK_DIV_2 | ADC_SHARED_TAD_MUL_33 | ADC_ENABLE_SHARED_CORE);
0452: CLR 30A
0454: MOV #1,W4
0456: MOV W4,304
0458: MOV #1F,W4
045A: MOV W4,306
045C: BSET.B 301.7
045E: BCLR.B 301.5
0460: CLR 402
0462: BSET.B 400.7
0464: BTSS.B 401.7
0466: BRA 464
0468: BSET.B 30A.7
046A: BSET.B 40B.1
046C: BCLR.B 40B.2
046E: BSET.B 40B.0
0470: BTSS.B 40B.7
0472: BRA 470
0474: BSET.B 40B.2
0476: BSET.B 40B.0
0478: BTSS.B 40B.7
047A: BRA 478
047C: BCLR.B 40B.1
047E: CLR 310
0480: CLR 312
0482: CLR 314
....................
.................... set_adc_channel(17);
0484: BCLR.B 314.3
0486: MOV #FFC0,W0
0488: AND 308
048A: MOV #11,W0
048C: IOR 308
....................
.................... while(1) {
....................
.................... the_reading = read_adc();
048E: MOV 308,W2
0490: AND #3F,W2
0492: MOV W2,W4
0494: MOV #10,W3
0496: REPEAT #11
0498: DIV.U W2,W3
049A: SL W0,#1,W2
049C: MOV #330,W0
049E: ADD W0,W2,W2
04A0: MOV #1,W0
04A2: SL W0,W1,W1
04A4: COM W1,W3
04A6: MOV [W2],W0
04A8: AND W0,W3,W0
04AA: MOV W0,[W2]
04AC: BSET.B 309.0
04AE: MOV [W2],W0
04B0: AND W0,W1,W0
04B2: BRA Z,4AE
04B4: SL W4,#1,W1
04B6: MOV #40C,W0
04B8: ADD W0,W1,W1
04BA: MOV W1,W4
04BC: MOV [W4],W0
04BE: LSR W0,#2,W0
04C0: SWAP W0
04C2: MOV.B W0L,1002
04C4: CLR.B 1003
.................... output_high(PIN_C5);
04C6: BCLR.B E20.5
04C8: BSET.B E24.5
.................... delay_us(the_reading);
04CA: MOV 1002,W0
04CC: CALL 400
.................... output_low(PIN_C5);
04D0: BCLR.B E20.5
04D2: BCLR.B E24.5
.................... delay_us(the_reading);
04D4: MOV 1002,W0
04D6: CALL 400
04DA: BRA 48E
.................... }
.................... }
04DC: PWRSAV #0
Configuration Fuses:
Word 1L: FFFF NOWRTB NOBSS NOBS NOWRT NOPROTECT NOWPCFG NOPROTECT_CFG NOAIVT
H: 0000
Word 2L: FFFF
H: 0000
Word 3L: FFFF
H: 0000
Word 4L: FFFF
H: 0000
Word 5L: FFFF
H: 0000
Word 6L: 7FFF
H: 0000
Word 7L: FFF8 FRC IESO
H: 0000
Word 8L: FF7A HS OSCIO IOL1WAY CKSNOFSM PLLWAIT
H: 0000
Word 9L: FF9F WPOSTS16 WPRES128 NOWDT WINDIS WDTWIN_25%
H: 0000
Word 10L: FFFF
H: 0000
Word 11L: FFDE ICSP2 NOJTAG NODEBUG NOBTSWP
H: 0000
Word 12L: FFFF PWMLOCK NOALTI2C1 NOALTI2C2 NODBCC
H: 0000
Word 13L: FFFF ALTWREG1=NO ALTWREG2=NO
H: 0000
Thanks in advance for any ideas. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jan 19, 2021 7:08 pm |
|
|
I assume you have seen the CCS example program: ex_adc_epgs.c
That program has several more setup lines than are in your posted code,
and some of the functions have different names than what you are using. |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Tue Jan 19, 2021 7:12 pm |
|
|
| PCM programmer wrote: | I assume you have seen the CCS example program: ex_adc_epgs.c
That program has several more setup lines than are in your posted code,
and some of the functions have different names than what you are using. |
Thanks for assuming the best (that I'd looked at that example file). Yes, I have looked at that. The additional lines are for the dedicated cores. All the ADC pins I'm using are shared ones (can't be used with the dedicated cores).
I've started looking at the assembly to see how each ADC register is being set. So far, no smoking guns. I'm open to any and all suggestions as I'm about out of ideas. I even replaced the PIC on the board in case somehow it was damaged. Behavior is identical. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 19, 2021 7:37 pm |
|
|
hmmm... this...
int16 the_reading;
any chance 'int16' for the dspic is defaulted to a SIGNED variable ??
that could easily give 'weird' numbers to the delay_us() function ??
I don't know if that's the case, just see similar 'oopsies' about types vs PICs here.
for test purposes , I'd be sending the ADC value to either a PC or LCD screen to SEE the results....
Jay |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Tue Jan 19, 2021 7:52 pm |
|
|
| temtronic wrote: | hmmm... this...
int16 the_reading;
any chance 'int16' for the dspic is defaulted to a SIGNED variable ??
that could easily give 'weird' numbers to the delay_us() function ??
I don't know if that's the case, just see similar 'oopsies' about types vs PICs here.
for test purposes , I'd be sending the ADC value to either a PC or LCD screen to SEE the results....
Jay |
Thanks for the thoughts. I originally was sending the value over CAN but wanted to make sure the problem wasn't somehow related to that so stripped the code down to the most basic possible. I just did this as a test that my ADC value is never going above 1 or 2:
| Code: |
while(1) {
the_reading = read_adc();
if(the_reading < 3) output_high(PIN_C5);
else output_low(PIN_C5);
delay_ms(10);
}
|
Pin C5 is always high. As mentioned previously, all of the ADC input pins have voltages that are around 1.65 V (verified). So I'd expect a return value from read_adc() substantially higher than 1 or 2 (oddly what is being returned - not zero. Some of the channels return 1 and some return 2).
I'm extremely puzzled, so glad for any and all ideas! |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Tue Jan 19, 2021 7:54 pm |
|
|
| temtronic wrote: | hmmm... this...
int16 the_reading;
any chance 'int16' for the dspic is defaulted to a SIGNED variable ??
that could easily give 'weird' numbers to the delay_us() function ??
|
Oh, and I did just try declaring it as unsigned int16 to be sure. No change. |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Wed Jan 20, 2021 12:17 am |
|
|
Interestingly, V5.100 was released tonight. I compiled my test program with it and compared the list files. Lo and behold, there are some changes. Previously today, I wasn't finding where the ADC bits was being set (#device ADC=xx). In the updated compiler, that is now being set. Also, there's something weird that was happening at the end of the read_adc() code (a swap after the right shift) which isn't there anymore. I'm not where my test setup is right now, but will be testing this first thing in the morning. I'm hopeful this solves the problem!
V5.099 section of the list file:
.................... the_reading = read_adc();
0494: MOV 308,W2
0496: AND #3F,W2
0498: MOV W2,W4
049A: MOV #10,W3
049C: REPEAT #11
049E: DIV.U W2,W3
04A0: SL W0,#1,W2
04A2: MOV #330,W0
04A4: ADD W0,W2,W2
04A6: MOV #1,W0
04A8: SL W0,W1,W1
04AA: COM W1,W3
04AC: MOV [W2],W0
04AE: AND W0,W3,W0
04B0: MOV W0,[W2]
04B2: BSET.B 309.0
04B4: MOV [W2],W0
04B6: AND W0,W1,W0
04B8: BRA Z,4B4
04BA: SL W4,#1,W1
04BC: MOV #40C,W0
04BE: ADD W0,W1,W1
04C0: MOV W1,W4
04C2: MOV [W4],W0
04C4: LSR W0,#2,W0
04C6: SWAP W0
04C8: MOV.B W0L,1002
04CA: CLR.B 1003
And the V5.100 section:
.................... the_reading = read_adc();
0498: MOV 308,W2
049A: AND #3F,W2
049C: MOV W2,W4
049E: MOV #10,W3
04A0: REPEAT #11
04A2: DIV.U W2,W3
04A4: SL W0,#1,W2
04A6: MOV #330,W0
04A8: ADD W0,W2,W2
04AA: MOV #1,W0
04AC: SL W0,W1,W1
04AE: COM W1,W3
04B0: MOV [W2],W0
04B2: AND W0,W3,W0
04B4: MOV W0,[W2]
04B6: BSET.B 309.0
04B8: MOV [W2],W0
04BA: AND W0,W1,W0
04BC: BRA Z,4B8
04BE: SL W4,#1,W1
04C0: MOV #40C,W0
04C2: ADD W0,W1,W1
04C4: MOV W1,W4
04C6: MOV [W4],W0
04C8: LSR W0,#2,W0
04CA: MOV W0,1002
And the ADC bits section that's now in V5.100 (missing on V5.099):
045E: MOV #40,W4
0460: MOV W4,302
I'll report in the morning how it goes. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19535
|
|
| Posted: Wed Jan 20, 2021 1:19 am |
|
|
Had you tried at all with earlier compilers?.
5.099, seemed to bring some significant ADC problems on some of the
DSPIC's. You will see that 5.100 says it fixes problems with some ADC's.
5.098, had other problems with pass_strings. 5.097 though was working
for me.
I was chasing a fix for some other issues I had, so have been 'chasing' these
versions. Currently testing 5.100.
Must admit, I walked through what you were doing, and it looked right
based on the example. Signed/unsigned shouldn't make any difference,
since everything here is in the low 12bits of the value. delay_us(x) has
limitations of some significant granularity on the output, generally much
easier to use a simple serial output.
Have you got the board flexibility to try one of the dedicated channels?.
Have you tried a different channel on the shared ADC?.
Try splitting the operation down into parts. So use START_ONLY,
and then a separate READ. Will help to show what the code is doing, and
might allow you to see the problem. I'd probably try manually turning off
the adc, loading ADMOD1 with 0, and turning back on. Will ensure all the
channels are set to single ended and the output format is standard
unsigned integer. |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Wed Jan 20, 2021 12:53 pm |
|
|
| Ttelmah wrote: | Had you tried at all with earlier compilers?.
5.099, seemed to bring some significant ADC problems on some of the
DSPIC's. You will see that 5.100 says it fixes problems with some ADC's.
5.098, had other problems with pass_strings. 5.097 though was working
for me.
I was chasing a fix for some other issues I had, so have been 'chasing' these
versions. Currently testing 5.100.
|
Unfortunately, all I had was V5.099 as I purchased it a couple days ago. I just started using the dspics.
But I'm happy to report that initial testing with V5.100 shows the ADCs functioning correctly - at least the readings look correct and nothing locks up.
Thanks everyone for the ideas. This forum is a huge part of the reason that I love CCS so much. You are all absolutely incredible. And while I'm not super excited to have spent an afternoon chasing after what ended up being a compiler bug, I am grateful that bugs are actively being squashed. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Wed Jan 20, 2021 12:55 pm |
|
|
| You'll find that ONCE CCS knows about a 'bug' ,they exterminate them fairly fast. When you consider the number of compilers, 1000s of PICs, it's amazing they CAN 'get out the bugs' so fast ! |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Wed Jan 20, 2021 1:00 pm |
|
|
| temtronic wrote: | | You'll find that ONCE CCS knows about a 'bug' ,they exterminate them fairly fast. When you consider the number of compilers, 1000s of PICs, it's amazing they CAN 'get out the bugs' so fast ! |
Great to know. What's the most effective way to officially report a bug to them? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Wed Jan 20, 2021 1:35 pm |
|
|
look up to the top right corner of this webpage....
'[email protected]' is in blue..... |
|
|
2xhp
Joined: 14 Jan 2019
Posts: 39
|
|
| Posted: Wed Jan 20, 2021 2:41 pm |
|
|
| temtronic wrote: | look up to the top right corner of this webpage....
'[email protected]' is in blue..... |
Okay, well yeah - that's the obvious answer. But I have yet to receive a response to an email I sent to that address a few days ago. So I was wondering if there was some less obvious effective way. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Wed Jan 20, 2021 3:17 pm |
|
|
Yes, it can take a few days. A lot depends on how much info you supply and how they can test the 'bug'. I don't know their staffing level and how easy it is to test a bug,then of course figure out HOW the bug got there, then ,sigh, figure out HOW to exterminate it, then of course MORE testing and then , hmm...is it just ONE PIC type or ALL of them ? Maybe just ONE series of compiler ?
Then there's the 'priority'... say you're number 15 on the list...they get 3 a day fixed...so 5 days they get to your bug BUT a whopper gets sent in, becomes #1, you're #2.....
Again I don't know how they do it,but I can see why it can take more than a day or two !
heck I was repairing a mower in garage, get interrupted, that interruption got interrupted and 3 DAYS later I finally get back to the original mower...great WHERE"S the $200 part that I KNOW I had for it....3 days ago, couple hours later found it !! Next to the phone in the garage....sigh.......
welcome to my world..... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
