• AVR Freaks

Hot!Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620)

Author
trossin
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2006/06/02 11:31:50
  • Location: 0
  • Status: offline
2019/09/25 17:15:41 (permalink)
4 (1)

Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620)

Please let me know if anyone else is seeing the issues I describe below.  Thanks for your help.
 
I just received new K parts from Microchip Direct (18F26K40 with 1632EPY date code) last week.  I also got a SNAP debugger card which connects and works well with MPLAB X IDE v5.25 but is unable to connect with MPLAB X IPE v5.25.  The SNAP debug/download comes back with: 
 
   Device Id Revision = 0xa0430000
 
This does not match the Errata document so I have no idea if it is an A3 or A4 device.
 
I see two big problems in the behavior and looking at the code generated by mcc it does not seem to be addressed:
 
1. ADGO takes two cycles to set so this code fails because ADGO is not set yet and ADRESH is returned before the conversion starts.  The work-around is to set ADGO twice before doing the wait for ADGO to return to zero: 
           ADCON0bits.ADGO = 1; 
           while(ADCON0bits.ADGO); // Wait for conversion to finish
           return(ADRESH);
 
The errata does talk about this issue but claims it is fixed in rev A4 parts.  Either it is not fixed or Microchip was not nice and sent me old crappy parts.  
 
2. When I run at 64MHz using the internal oscillator, I can't get the full range of results unless I use the slow FRC clock.  When I tried using Fosc with the slowest setting (ADCLK to 0x3f), I could see the high 8 bits get up to 0xe0.  With ADCLK set to 0x1f which should have a tAD of 1us it only got up to 0xb0.  The spec says tAD is 1us to 9us.  Both of these failures were when I had the input set to +5V.  Another problem I ran into was when trying to interface to a joy stick which simply switches between two channels (RA0 and RA1).  When I did this I found that if one channel was above a volt or so that the other channel would not read 0 when it was at 0V.  I found this gem in the data sheet:
 
    "It is recommended that when switching from an ADC channel of a higher voltage to
     a channel of a lower voltage, the software selects the Vss channel before switching"
 
So, I added code to switch the source to read 0 (ADPCH = 0x3c) before setting the channel and that had no effect.  What worked was to selected 0, delay 100us  then set the source select to my desired channel and I was able to read 0V as a 0.  The data sheet does not say how long to wait.  So my joystick reads almost work except, I can't get the full range.  I found that going back to FRC mode that I did not need to select 0 first. 
 
The only way to use the ADC with a 64MHz internal clock seems to be to use the FRC clock.
 
The full range error is not mentioned in the errata.
 
#1

10 Replies Related Threads

    Lurch
    Super Member
    • Total Posts : 644
    • Reward points : 0
    • Joined: 2010/08/04 14:05:04
    • Location: 0
    • Status: online
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/09/26 04:36:43 (permalink)
    +1 (1)
    Device Id Revision = 0xa0430000
    In my errata DS80000712E (from 2018) this is clearly listed as version A3. You should download a newer version of the errata.
    #2
    trossin
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2006/06/02 11:31:50
    • Location: 0
    • Status: offline
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/09/26 07:34:11 (permalink)
    0
    Thanks. It seems that Microchip sells their old stock to unsuspecting saps like me. Next time I’ll order from Mouser. I downloaded the errata yesterday so I’ll try again. Does your version have any info about the broken behavior that I’m seeing when not using the FRC clock?

    I’ve been a Microchip fan for nearly two decades and have posted projects here:

    https://www.sites.google....n/home/electronics/pic
    #3
    trossin
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2006/06/02 11:31:50
    • Location: 0
    • Status: offline
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/09/26 07:34:11 (permalink)
    0
    N
    post edited by trossin - 2019/09/26 07:35:12
    #4
    trossin
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2006/06/02 11:31:50
    • Location: 0
    • Status: offline
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/09/26 14:05:39 (permalink)
    0
    So the errata I downloaded was the same file but ended in F instead of E.  I searched Microchip's site and got no matches ending in E so it seems that it has been removed.  From the F file I found this week here:
     
    http://ww1.microchip.com/downloads/en/DeviceDoc/PIC18LF26-45-46K40-Errata-80000712F.pdf
     
    Table 1. Silicon Device Identification
    Part Number Device ID Revision ID A3 A4
    PIC18F26K40  0x6980 0xA003 0xA004
    PIC18LF26K40 0x6A60 0xA003 0xA004
    PIC18F45K40  0x6940 0xA003 0xA004
    PIC18LF45K40 0x6A20 0xA003 0xA004
    PIC18F46K40  0x6920 0xA003 0xA004
    PIC18LF46K40 0x6A00 0xA003 0xA004


     
    I'm not sure how you can tell that this responses from the debugger is clearly an A3 part.
    Device Id Revision = 0xa0430000
     
    Am I supposed to ignore the low 16 bits and the 4 in bits 23:20?
     
    Thanks.
     
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 17942
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/09/26 14:17:19 (permalink)
    +2 (2)
    trossin
    Thanks. It seems that Microchip sells their old stock to unsuspecting saps like me. Next time I’ll order from Mouser.



     
    All Distributors sell out the Old stock First.
    If you need a few to test, you can request them from an F.A.E. or through Samples.  For Production Quantities  the REV would Need to be requested.
    #6
    Jams100001
    Junior Member
    • Total Posts : 67
    • Reward points : 0
    • Joined: 2018/04/12 13:37:33
    • Location: MCHP Chandler
    • Status: offline
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/10/04 15:58:32 (permalink)
    +1 (1)
    @64Mhz the TAD is too short.  TAD should be in the range for the conversion to happen successfully. Table 31-2 shows the values but notice note 2 says some of them violate the required TAD time for conversion. the only two allowed for a good conversion @64Mhz is Fosc/128 or FRC.
     
     
    #7
    trossin
    New Member
    • Total Posts : 23
    • Reward points : 0
    • Joined: 2006/06/02 11:31:50
    • Location: 0
    • Status: offline
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/10/11 18:23:58 (permalink)
    0
    I used Fosc/128 with a setting of ADCLK=0x3f and the device still behaved badly.  The spec says tAD should be between 1us and 9us.  So settings of 0x20 (1us) to 0x3f (2us) should behave correctly but the device fails horribly.  It seems that there needs to be an errata that the spec is wrong.  There also should be a mention of how long to wait when changing channels with the selection of zero.  I waited 100us to get it to work when not using the FRC clock.
     
    This goes back to my original question about whether it is just me or is this just another bug in the device which can be worked around by using the FRC clock.
    #8
    nigelwright7557
    Super Member
    • Total Posts : 308
    • Reward points : 0
    • Joined: 2006/11/06 08:15:51
    • Location: 0
    • Status: offline
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/10/11 22:03:00 (permalink)
    0
    ADCON0bits.ADGO = 1; 
               while(ADCON0bits.ADGO); // Wait for conversion to finish
               return(ADRESH);
     
    This isn't a fix, thats how its supposed to be done.
    ADGO is also the /done bit too.
    So /done must be low before ADRESH is valid.
    #9
    ric
    Super Member
    • Total Posts : 24282
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/10/11 22:45:15 (permalink)
    0
    nigelwright7557
    ADCON0bits.ADGO = 1; 
             while(ADCON0bits.ADGO); // Wait for conversion to finish
             return(ADRESH); This isn't a fix, thats how its supposed to be done.ADGO is also the /done bit too.So /done must be low before ADRESH is valid.

    You've totally misunderstood the point in the first post.
    It is saying that correct code fails in older revision chips because ADGO does not get set immediately.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #10
    Lurch
    Super Member
    • Total Posts : 644
    • Reward points : 0
    • Joined: 2010/08/04 14:05:04
    • Location: 0
    • Status: online
    Re: Issues with 18F26K40 A/D (Seems messed compared to old trusty 18F1330 or 18F2620) 2019/10/12 02:21:49 (permalink)
    0
    with IPE I get this on connect:
    Currently loaded firmware on PICkit 3
    Firmware Suite Version.....01.56.00
    Firmware type..............Enhanced Midrange
    Target voltage detected
    Target device PIC18F46K40 found.
    Device Revision ID = a044


    attached is the DS80000712E table as .jpg
    Looks like the F version wrote the revision codes wrong. A3 is A043 (I have an A4 part - as Sample from MCHP)
     

    Attached Image(s)

    #11
    Jump to:
    © 2019 APG vNext Commercial Version 4.5