• AVR Freaks
Reply to post

Hot!MCP79510 - problems with VBAT, Timing accuracy

Author
shashialabur
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2008/11/13 04:18:50
  • Location: 0
  • Status: offline
2017/08/22 23:46:39 (permalink)
0

MCP79510 - problems with VBAT, Timing accuracy

Hi,
I am using a MCP79510 RTC device with a PIC16F887 microcontroller.
I have no problem with the Read or Write of the 79510.
However :
Problem #1 :  When I write Register 0x08 with 0x43 (SQWEN = 1, CRSTRIM = 0, SQWFS<1:0> = 11), I get a rock steady 32.768KHz signal output on the MFP pin, which my frequency counter measures with utmost +/-1 count as 32768 or 32769 Hz. Register 0x09 is set to TRIMVAL = 00000000 to disable Digital Trimming. But, with the above settings, the RTC runs at almost 6 times the normal speed !! The minutes increment almost once every 10 seconds. Thinking the layout is a problem, I made an external oscillator and fed a clean 32768Hz signal, but the same 6x speed of the RTC ! I even made a small breadboard with only the 79510 device and connected the digital signals to the main board, but same result. If I enable Coarse trim (CRSTRIM = 1) and set TRIMVAL = 0xFF (TRIMSIGN = 0), then the RTC runs at near normal speed. WHY ? What is the issue here ?
 
Problem #2 :  VBATEN bit does not stay enabled. During the normal Powered up condition VCC = VBAT = 3.30V, when powered down VBAT = 3.15V to 3.21 V. If I read the VBATEN bit after a physical power up, it shows as 0, but after the RTC init sequence in my code, if I reset the board when using the Debugger and restart, then I get VBATEN = 1. I am quite certain that there is no momentary loss of voltage on the VBAT pin. I have used this same Battery back up circuitry in more than 20 products over the past 20 years and never faced a problem ! So, again, what could be the problem here ?

16 Replies Related Threads

    qhb
    Superb Member
    • Total Posts : 9998
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2017/08/23 00:01:08 (permalink)
    0
    My first suspicion would be a bug in your code.
    You did not mention if you're programming in C or assembler, or how exactly you are checking the minutes register.
     
    shashialabur
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2008/11/13 04:18:50
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2017/08/23 01:06:12 (permalink)
    0
    Hi,
    I am writing in Assembler, using ICD3, MPLAB 8.80.
    My code to read the registers is the same when CRSTRIM=0 or 1.
    I tried reading all registers from 0x01 to 0x07 in one cycle, or one register at a time, but same result.
    In the Debug mode, if I read the RTC once and then stop RUN, and then read again after a minute, I find that the time has incremented by 6 minutes. If I read once after 5 minutes, the time has incremented by 30 minutes.
     
    The same code, with CRSTRIM=1, TRIMVAL=0xFF, TRIMSIGN=0 gives me reasonably accurate time (14 minutes slower after about 16 hours)
     
    qhb
    Superb Member
    • Total Posts : 9998
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2017/08/23 03:13:00 (permalink)
    0
    Possibly your crystal is unstable.
    What crystal and caps are you using?
     
    RISC
    Super Member
    • Total Posts : 5376
    • Reward points : 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2017/08/23 04:33:58 (permalink)
    3 (1)
    Hi,
    As QHB mentioned your issue is most probably the SW.
    Did you notice that the results are NOT in HEX but in BCD format ???
    0x10 in BCD is 10 in decimal (not 16...)
    Read carefully documentation section 5.3
    Regards
    PS : please also read carefully the MCP795xx erratasheet. You should make sure that you follow the workarounds if needed
    post edited by RISC - 2017/08/23 04:51:20
    shashialabur
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2008/11/13 04:18:50
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2017/08/23 06:32:51 (permalink)
    3 (1)
    qhb
    Possibly your crystal is unstable.
    What crystal and caps are you using?
     

    The timing problem has been the same when
    a) the 32768Hz square wave output at the MFP pin is rock solid, with no jitter, where the Frequency Counter shows 32768 or 32769
    b) I used an external oscillator with a clean 32768Hz output (where the same external oscillator feeds a DS1306 RTC in another older board and that has no accuracy issues).
    If it was a small error, I would agree, but to go at 6x speed ?
    The crystal used is one that we buy in bulk from China, with 12pf capacitance.
    We use the same crystal and cap's in our other boards with DS1306 and a much older MSM6242 clock IC's and we don't have any problem there.
     
    If the MCP795xx devices are so sensitive, then they may not be suitable for my industrial product !
     
    RISC
    Did you notice that the results are NOT in HEX but in BCD format ???
    0x10 in BCD is 10 in decimal (not 16...)
    Read carefully documentation section 5.3
     

    Yes, I am aware that the read values are in BCD. So, if i read 17 45 for the hours and minutes, then it 5.45pm.
     
    As I said in my previous post, if i stop the board when using the debugger, (the code is not running and no READ_RTC functions are being called, though the RTC is powered up and running) and if I do one read cycle after 5 minutes, the time has incremented by 30 minutes. A read immediately after the write gives me back the time that was written into the RTC.
     
    And, if I do the clock adjustment with Coarse trim (CRSTRIM = 1), TRIMVAL = 0xFF and (TRIMSIGN = 0), then the RTC runs at near normal speed.
     
    So, it is not the crystal stability or the capacitors or the code, wouldn't you say ?
    Ron
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2017/04/08 18:21:18
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/25 11:25:47 (permalink)
    0
    Hi,
    I just wanted to add my two cents worth to the conversation.  I'm working on a project using an MCP79520 with similar problems.  What I did was to set up a quick "operational test" to output a square wave from the MFP.  Briefly, the SQWFS bits can select 32.768KHz, 8.192KHz, 4.096KHz, and 1Hz. The 32.768KHz frequency is essentially direct with the other frequencies routed through a Postscaler. The 32.768KHz setting produces 32.774KHz (6Hz high - not a problem at this point) and the oscillator signal is rock-solid at that frequency, while the 8.192 setting produces 21.849KHz, the 4.096KHz setting produces 8.194KHz, and the 1Hz setting produces 2Hz.  In addition to this, any setting other than the 1Hz setting "locks up" the SPI I/F.  I have a support ticket in on the issue, but so far rather than involving engineering and attempting to duplicate the malfunction, all I get is suggestions to try a number of "guesses" some of which are unrelated to the problem.  I am programming in C, but frankly I would put more trust in assembler simply because with assembler you know what is happening, and with C you're never quite sure.
    Having used other RTC chips over the years, I'm not sure this is the device I would to trust in a new product design.  Given everything I have learned, the chip just has too many glitches and support doesn't seem to have a good handle on the issues.  I'm currently in the process of ordering another device for evaluation - this time chosen for performance and not price - but I will continue to forge ahead with the support ticket to see if they eventually come up with a solution, or at the very least an explanation...
    Regards, Ron
    NKurzman
    A Guy on the Net
    • Total Posts : 17623
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/25 11:47:13 (permalink)
    5 (1)
    If you are not sure what C does, but need to know, then look at the ASM it generates.
    LdB_ECM
    Senior Member
    • Total Posts : 125
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/25 11:51:13 (permalink)
    0
    It's a bug when using an xtal there is an errata notes .. the time goes like at twice the rate I have that on my board as well and was amusing until I found the errata.
     
    There are a couple of other gotcha bugs as well
    http://ww1.microchip.com/...n-Errata-80000680D.pdf
    NKurzman
    A Guy on the Net
    • Total Posts : 17623
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/25 12:22:35 (permalink)
    5 (1)
    Always Read the Errata before choosing any Chip.
    Ron
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2017/04/08 18:21:18
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/26 10:05:48 (permalink)
    0
    Hello All,
    I just wanted to respond to NKurzman's comment that "If you are not sure what C does, but need to know, then look at the ASM it generates". I don't intend to be facetious here, but wouldn't it be more efficient to simply write in assembler so you would know what the code does?  Just an observation...
    In any event, I am currently learning C because every application I have been involved with over the last several years seems to be written in C so if I need to "communicate" with software types, you have to speak C.  I had to quit writing in assembler because nobody I was working with could figure out what the heck my code was doing.
    In any event, my code works, but at the sacrifice of clarity compared with assembly code.  Perhaps it's just a training issue...
    A word about the errata sheet: I found the errata sheet AFTER I had designed the part into the product.  Since I downloaded the original sheet - which addressed 5 issues - the errata that LdB_ECM linked to has a 6th issue that essentially says don't use the 32KHz or 8KHz square wave outputs.  Not sure how this works - the 8KHz and 4KHz settings come from the Postscaler, while the 32KHz is a "Direct" output (refer to page 27 of the data sheet).  Also, most of the "work around" fixes do not seem to consider the RTC being used in a stand-alone product that has to have the current "accurate" time available every time the MPU accesses the chip. Period. The chip also has to be able to maintain accurate time while running in battery backup mode and it seems to have a problem switching from Vcc to Battery and vice-versa.
    Anyway, thanks to everyone who responded.  Not sure this chip is "ready for prime time" (pun intended).
    Regards, Ron
     
    mlp
    boots too small
    • Total Posts : 779
    • Reward points : 0
    • Joined: 2012/09/10 15:12:07
    • Location: previously Microchip XC8 team
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/28 09:48:23 (permalink)
    0
    R0nz4232
    Hello All,
    I just wanted to respond to NKurzman's comment that "If you are not sure what C does, but need to know, then look at the ASM it generates". I don't intend to be facetious here, but wouldn't it be more efficient to simply write in assembler so you would know what the code does?  Just an observation...

    The important precondition here is "If you are not sure what C does".
    Once you're comfortable with the language, you develop much more confidence in "what the code does", at which point your efficiency goes way up in C.
     
     

    Mark (this opinion available for hire)
    Ron
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2017/04/08 18:21:18
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/28 10:50:13 (permalink)
    0
    mlp,
    I agree.  I have found that the more code I write in C the more I understand how to make it work the way I intend it to.  I also am pretty sure that there is a reason C exists in the first place, that it seems to be arguably the most popular programming language in use today, and it is supposedly much easier than "coding" in assembly language. 
     
    Having done both, I'm still waiting to have the epiphany that makes C easier, faster, and more popular (with me) that programming in machine code (sorry, I couldn't help using the archaic term for coding...).
     
    I have a friend who speaks fluent Swahili and is amused that I am simply unable to repeat simple phrases in the language.  He claims that he finds English difficult and confusing.
    Maybe if I had "grown up" speaking C...
    Regards, Ron
     
    mbrowning
    Just a Member
    • Total Posts : 1469
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/28 11:27:22 (permalink)
    0
    R0nz4232
    programming in machine code (sorry, I couldn't help using the archaic term for coding...).

    Assembly is not machine code and machine code is not an archaic term for coding. It's what the machine runs. You'd have to go back to flipping switches on the front of an Altair (or writing your own hex files in a text editor) to be programming in machine code.

    Oh well - there's always next year
    mbrowning
    Just a Member
    • Total Posts : 1469
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/28 11:27:11 (permalink)
    0
    dup post

    Oh well - there's always next year
    Ron
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2017/04/08 18:21:18
    • Location: 0
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/28 16:54:53 (permalink)
    0
    mbrowning,
    You got me!  I made the mistake of calling assembly language machine code.  Deep in the recesses of my faulty memory I was aware that compiled assembly code produces machine code, but fell into the trap of calling it machine code like some others have mistakenly called it (actually, it's a fairly common mistake).  I should have said "programming in assembly language", although this is probably incorrect as well...
    What I was referring to was using the term "programming" rather than "coding".  Some of us old farts still refer to writing a program as programming, but I have been corrected by some professional programmers (coders?) that when I'm writing C, I'm actually "coding".
    Incidentally, I have had the experience of "programming in machine code" as you call it by flipping switches to enter the routine into not an Altair, but a home-brew with a similar architecture.  As for programming in machine code, my earliest experience (around 1967 or so) was programming the computer of the N5G inertial navigation system in the AGM28 Hound Dog missile using the continuity and logic test set (pushbuttons rather than toggle switches).  It was tedious, but a great learning experience.
    By the way, you forgot to mention that compiled C code also produces machine code...
    Did not mean to start an argument.
    Peace.
    Regards, Ron
     
     
    ric
    Super Member
    • Total Posts : 23259
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: MCP79510 - problems with VBAT, Timing accuracy 2019/06/28 17:11:53 (permalink)
    0
    R0nz4232
    ...
    Having done both, I'm still waiting to have the epiphany that makes C easier, faster, and more popular (with me) that programming in machine code

    Stick at it Ron.
    I programmed PIC16F parts exclusively in assembler for about 15 years (including several commercial products), before shifting to C about 8 years ago.
    I'll still use some inline assembler if I have a small loop which needs utmost speed, but 95% of my code doesn't, and it is so much more productive to do it in C.

    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!
    Guest
    Quick Reply: (Open Full Version)
      Enter the random characters shown
    Submit Post
    Some restrictions apply to prevent link (URL) Spam.
    URLs in messages, signatures, and PM's are removed unless you have ...
    • been a member for at least 0 day(s);
    • made a total of 0 post(s);
    • earned at least 0 point(s) for post scores (based on the ratings on your posts);
    • earned at least 0 reward point(s);
    Jump to:
    © 2019 APG vNext Commercial Version 4.5