I got the internal RTC to work fine on the PIC16F19156 using the GCB example code with suitable mod's for my serial LCD type. However, I connected a lithium-ion cell to the Vbat (Pin 7 VBAT/RA5) but whatever logic I give the VBATEN (Vbat enable ON or OFF ), the RTC does not maintain the time, when the main power is lost. I am trying to run the clock from an external 32.768 crystal connected to RC0 &RC1 (with recommended capacitors).... (SOSC= 'Secondary Oscillator') I suspect my problem may be that I have not selected SOSC for the RTC clock oscillator. Is there a command in GCB to do this please?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I built the demo with Microchip development when the part was released. I have it working here. So, without your program and the pinout of your config - I would be guessing.
* Microchip Comments Start **
Microchip Engineering SupportCase 00258560.
Check the datasheet for this PIC, in TABLE 3:28-PIN ALLOCATION TABLE PIC16(L)F19155/56), it shows which pins you need to connect the SOSCI and SOSCO to.
Let me explain further.
If you are using a 28-Pin SPDIP/SSOP/SOIC device, SOSCO is on pin 11 which is RC0 and SOSCI is on pin 12 which is RC1. If you are using a 28-pin UQFN device, SOSCO is on pin 8 which is RC0 and SOSCI is on pin 9 which is RC1. This is fixed and cannot be changed.
Now, regarding the CAP specification values, our recommendation is to follow the guidelines given in the crystal oscillator datasheet.
Other than that, you can look at the following application note: http://ww1.microchip.com/downloads/en/AppNotes/00001798a.pdf . On page 3, under the heading Load Capacitance it gives formulas to calculate the C1 and C2. Here, the CL refers to capacitance value mentioned in the crystal oscillator datasheet. Even though this document refers to PIC24 devices, it will apply to our device as well.
There is no app note specific to this PIC like you wanted. So, I cannot provide you with that.
Hope it is more clear to you now.
Best Regards, * Microchip Comments End ***
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I have the crystal on the correct pins (11 &12) as I am using 28pin SOIC version. I will study the CAP app note .. I was merely using the capacitance suggested by the crystal manufacturer.
I was hoping that this addition belo, to the original code you did, would allow me to enable the RTC clock as SOSC. My query is what is the correct value of rtccLKSEL0 & rtccLKSEL1 for the SOSCI
All very new to me so sorry for my ignorance
INTOFF
Wait 1 s 'Wait stabilisation
RTCCON.rtccLKSEL0 = 0 'POR Default
RTCCON.rtccLKSEL1 = 0 'POR Default
RTCCON.RTCWREN = 1 'MUST Write this bit before RTCEN
Wait 100 ms 'Wait for SOSC to stabilise
INTON
Best regards and thank you foryour kind help.. Ash
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So is the demo programme you have working from an external crystal and a battery back-up on power removal? I just put a 'scope on the crystal pins and got a clean 32.768 khz waveform with power applied but with the battery connected to VBAT pin the signal disappears on power down.( I would have xpected it to be present even with the power off and the RTC presumably powered from the external battery.
Do you have a link to the Dev board you used please?
Thanks ... Ash
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The board is Great Cow BASIC demonstration board. It is large but standard.
The code was published in 2017. So, I am thinking.
Have you chang the demo ? or the library?
I am working the USB project at the moment - I am reluctant to break down my setup - unless I really need to.
Last edit: Anobium 2018-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No worries I don't want to desturb you ...I will persevere next week with this as I am away for a few days now.
I merely changed the code in the RTCC example for the PIC16F19156 slightly to suit my serial LCD . I can see a line in the original programme which enables / disables VBAT but I can't fathom where the RTC oscillator is set to use SOSC rather than the internal clock.
thanks again .. Ash
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The SOSC is set in the library. As the is called automatically this is set for you.
INTOFF
Wait 1 s 'Wait stabilisation
RTCCON.rtccLKSEL0 = 0 'POR Default
RTCCON.rtccLKSEL1 = 0 'POR Default
RTCCON.RTCWREN = 1 'MUST Write this bit before RTCEN
Wait 100 ms 'Wait for SOSC to stabilise``
I do remember having major issues. (But, I have lots of open Microchip tickets). And, it was with the CAPS and keeping the external clock source operational. Just cannot remember how I resolved.
Check back later in the week - meanwhile check the caps, your VBAT connection.
BUT! what version of Great Cow BASIC? What are you using to compile and link? Are you on the latest version and using Great Cow BASIC to compiler and generate your Hex?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Ash. I am experiencing the same issue. I was incorrect. Unless you have fixed... I think we have an issue.
My finding. The RTCC operates as expected butthe following issues are happending.
RTCC is VERY slow to become operational.
RTCC with VBAT is not operating as expected.
Notes: #1.
- RTCC is operating once RTCSYNC = 1.
- From oscilloscope examination the crystal clock is taking ~10seconds to stablise.
Note: #2
- When power is removed from main circuit the RTCC stops.
- When power is removed from main circuit the current draw on VBAT is ~3ma.
- When power is removed from the main circuit the clock crystal stops oscillating. There is NO recovery from this situation.
Note: #3
- When power is restored to main circuit the RTCC restarts with 5 secs added to the last viewed time.
Same with your solution? Anything to add?
I have re-opened the Ticket with Microchip. I truly thought this was working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the .h library, insert at line 104 the following - this will resolve one issue of the slow start up of the crystal clock and set the SOSC power correctly. This will not resolve the VBAT issue.
'CSWHOLD may proceed; SOSCPWR High power;
CSWHOLD = 0
SOSCPWR = 1
And, change the config in the main program as follows:
#chip 16F19156, 0.03267
#option Explicit
#config BOREN = OFF, VBATEN=On, LPBOREN=OFF, RSTOSC = SOSC 'for the battery support (VBAT)
With these changes the RTCC clock works as expected. This is not clear by using the datasheet! You were totally correct that we needed to select SOSC as the clock source.
I think you will have to sort the brown-out event, like reseting the LCD etc etc - hopefully the VBAT event sets a bit somewhere as The I2C bus and the LCD will get reset by the power out (if you use the demo that is).
Let me know how you get on. Sorry for the delay and not getting the SOSC correct.
Last edit: Anobium 2018-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"RSTOSC=SOSC" will set the primary clock (FOSC) to 32.768KHz and should not be necessary for RTC operation. The secondary oscillator (SOSC) should operate independantly from the main clock (FOSC).
Seems to me that you would want to enable the secondary oscillator after FOSC has stabilized. Then enable the RTC. I do not have this chip on hand but this is how I would try to do it, assuming that the internal clock source is used for FSOSC.
#chip 16F19156,16
#config FEXTOSC= OFF, RSTOSC = HFINT32
#config VBATEN = ON, LPBOREN=OFF, LPV = ON
#option explicit
wait 10 ms '// Probably unnecessary
'// Setup and enable SOSC/Secondary clock for RTC
SOSCPWR = 1 '// Use high Power for SOSC (May not be necessary)
SOSCEN = 1 '// Manually Activate Secondary Oscillator
Do while SOR <> 1 '// Wait for SOSC ready bit high
Loop
'// Setup and enable the RTC
RTCWREN = 1 '// Must set this bit first
RTCCLKSEL0 = 0 '// Redundant
RTCCLKSEL1 = 0 '// Redundant
RTCEN = 1 '// Start RTC
Last edit: William Roth 2018-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Bill. I was willing to try, I just did, but that config fails.. The clock fails when main power is removed.
I went through a lot of testing yesterday, and, I am with you regarding the RSTOSC. Hence, opening a ticket on this - I had lots of issues with this part when I got on test last year and all to do with the RTCC. Waits are needed, I found an issue with the LPBOREN and a lack of good examples.
Anyway, I did try. I thought you had cracked it. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2. Module: Real Time Clock and Calendar
(RTCC)
The RTCEN bit of the RTCCON register is synchronized to the SOSC and will not be set until the external oscillator is available. The first time that the RTCEN bit is set, there could be a delay between when the bit is set in software and when the bit is set in the RTCCON register, if an external crystal is used as the clock source. This potential delay is based upon the start-up time of the crystal, as the RTCEN bit of the RTC CON register will not set until the external oscillator is stable and ready. The start-up time of the specific external crystal must be considered when initializing the RTCC module to ensure that the RTCC module is enabled before the RTCWREN bit is cleared. It is recommended that the RTCEN bit is polled after setting it to ensure that it is set before clearing the RTCWREN bit.
Is it the config that is incorrect or something else? Before concluding a bad or incorrect config, I would do the following to help narrow down the problem. Is it the SOSC ot RCT not starting or something else?
Check that the SOSC is running when set manually by checking the state of SOR bit In OSCSTAT. If SOR bit is set then SOSC should be running.
IF SOSC is not starting, the set SOSCPWR to 0 and test again. On other Chips with SOSC I have fond that 10 - 12 nF caps work well with clock crystals.
Try using MFINTOSC as the RTC Clock source (as a test) by setting MFOEN bit in OSCEN and setting RTCCLKSEL1 in RTCCON
Per Note above, poll the RTCEN bit to see it it is ever being set.
If this is only an issue with SOSC/RTC not operating with VBAT and backup battery then disregard the above. Let Microchip resolve it.
Last edit: William Roth 2018-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for all of your efforts everyone. I just got back to work today, so I am trying everthing suggested. I guess from your comments that we now need to wait for Microchip to respond. I don't mind waiting for their responce and hopefully the loss of clock on power-down can be fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi .. I tried the fix but it still doesn't retain corect time on power cycling. In the Dropbox link below I included your code, suitably modified for my serial LCD setup and input buttons and the modified .h header file. I also videoed the clock setup (in the link) to show system powered down and losing it's settings along with a scope trace of the RC0 pin, which displays a steady 32.768kHz on RA5 until the main power is lost. The other trace on the scope is the VBAT input (RA5) , which shows a constant 4 VDC but the clock is lost on power down, despite the VBAT pin having 4v on it constantly. Or have I misunderstood and we are waiting for a suggested fix from Microchip for this?
Thanks again for all of your kind help and the recommedation of this really powerful, inexpensive and versatile chip (PIC16F19156)
P.S. I used a main clock setup of 16 (as suggested by William) as I assumed that the secondary oscillator is merely that of the added crystal's frequency (I.e. 32.768 kHz )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried an experiment ...I removed the external crystal and made sure that the clock stopped incrementing ....which it did. This proves to me that the clock is indeed using the SOSC now, so it's just the VBAT issue I have now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the same post as above. This works in terms of keeping the clock running. I have removed extra words.
@Ash. Fix #1
In the .h library, insert at line 104 the following - this will resolve one issue of the slow start up of the crystal clock and set the SOSC power correctly. This will not resolve the VBAT issue.
'CSWHOLD may proceed; SOSCPWR High power;
CSWHOLD = 0
SOSCPWR = 1
And, change the config in the main program as follows:
#chip 16F19156, 0.03267 'any below 8 mhz works
#option Explicit
#config BOREN = OFF, VBATEN=On, LPBOREN=OFF, RSTOSC = SOSC 'for the battery support (VBAT)
You were totally correct that we needed to select SOSC as the clock source.
This however is NOT a working solution - as I said when the main power is restored the event needs to captured and resolved. I have opened a ticket with Microchip as I cannot figure it out.
What is the correct config?
Why does the OSCFREQ have an impact on the SOSC when SOSC is the selected OSC.
How do we handle the power restore event if we have disabled BOREN and LPBOREN?
I have previously asked Microchip for an APPNOTE on the RTCC. I have just checked ny findings... same as last week and I still do not know how to resolve - we need Microchip.
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Microchip support did some tests on PIC16F19155 andthey succeded to obtain your required functionality using SOSC + DIVIDER=2. They provided a project to the case (testPIC16F19156_RTCC.X.zip).
They configured the device for starting using SOSC then in the software I switched the clock to HFINTOSC (32Mhz).
The project is MCC based so, they used different routines to re-configure clock and UART.
For testing they used the following pins: CLKOUT, RC3(RTCC), RC4(UART TX). The UART baudrate is 300 bps.
I compiled and tested.
Result of the tests was a fail.
My response:
Thank you.
Did you test on real hardware? I compiled etc. All good for that.
Yes the clock runs. When I remove the power, with VBAT attached, clock stops. This is the error I am trying to resolve.
I am being told Microchump. The RTCC when the main VCC is removed will only keep the time at the point of power off with VBAT powered. When main VCC is restored the RTCC with continue from where is left off. Therefore, a 10s power cut will cause the clock to loose 10s.
Tell me this is bonkers! Madness!!
Surely, the RTCC when the main VCC is removed will keep the time whilst the VBAT is powered. And, when RTCC is restores RTCC will still be correct.
Anyone got a view?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got the internal RTC to work fine on the PIC16F19156 using the GCB example code with suitable mod's for my serial LCD type. However, I connected a lithium-ion cell to the Vbat (Pin 7 VBAT/RA5) but whatever logic I give the VBATEN (Vbat enable ON or OFF ), the RTC does not maintain the time, when the main power is lost. I am trying to run the clock from an external 32.768 crystal connected to RC0 &RC1 (with recommended capacitors).... (SOSC= 'Secondary Oscillator') I suspect my problem may be that I have not selected SOSC for the RTC clock oscillator. Is there a command in GCB to do this please?
I suspect your assumption maybe incorrect.
I built the demo with Microchip development when the part was released. I have it working here. So, without your program and the pinout of your config - I would be guessing.
* Microchip Comments Start **
Microchip Engineering SupportCase 00258560.
Check the datasheet for this PIC, in TABLE 3:28-PIN ALLOCATION TABLE PIC16(L)F19155/56), it shows which pins you need to connect the SOSCI and SOSCO to.
Let me explain further.
If you are using a 28-Pin SPDIP/SSOP/SOIC device, SOSCO is on pin 11 which is RC0 and SOSCI is on pin 12 which is RC1. If you are using a 28-pin UQFN device, SOSCO is on pin 8 which is RC0 and SOSCI is on pin 9 which is RC1. This is fixed and cannot be changed.
Now, regarding the CAP specification values, our recommendation is to follow the guidelines given in the crystal oscillator datasheet.
Other than that, you can look at the following application note: http://ww1.microchip.com/downloads/en/AppNotes/00001798a.pdf . On page 3, under the heading Load Capacitance it gives formulas to calculate the C1 and C2. Here, the CL refers to capacitance value mentioned in the crystal oscillator datasheet. Even though this document refers to PIC24 devices, it will apply to our device as well.
There is no app note specific to this PIC like you wanted. So, I cannot provide you with that.
Hope it is more clear to you now.
Best Regards,
* Microchip Comments End ***
Hi thanks,
I think I have the crystal on the correct pins (11 &12) as I am using 28pin SOIC version. I will study the CAP app note .. I was merely using the capacitance suggested by the crystal manufacturer.
I was hoping that this addition belo, to the original code you did, would allow me to enable the RTC clock as SOSC. My query is what is the correct value of rtccLKSEL0 & rtccLKSEL1 for the SOSCI
All very new to me so sorry for my ignorance
INTOFF
Wait 1 s 'Wait stabilisation
RTCCON.rtccLKSEL0 = 0 'POR Default
RTCCON.rtccLKSEL1 = 0 'POR Default
RTCCON.RTCWREN = 1 'MUST Write this bit before RTCEN
Wait 100 ms 'Wait for SOSC to stabilise
INTON
None of that should be required. The demo and the library should work.
There is no need to change the clock source. The part clock can be is independent of the RTCC clock source.
So is the demo programme you have working from an external crystal and a battery back-up on power removal? I just put a 'scope on the crystal pins and got a clean 32.768 khz waveform with power applied but with the battery connected to VBAT pin the signal disappears on power down.( I would have xpected it to be present even with the power off and the RTC presumably powered from the external battery.
Do you have a link to the Dev board you used please?
Thanks ... Ash
The board is Great Cow BASIC demonstration board. It is large but standard.
The code was published in 2017. So, I am thinking.
Have you chang the demo ? or the library?
I am working the USB project at the moment - I am reluctant to break down my setup - unless I really need to.
Last edit: Anobium 2018-06-13
No worries I don't want to desturb you ...I will persevere next week with this as I am away for a few days now.
I merely changed the code in the RTCC example for the PIC16F19156 slightly to suit my serial LCD . I can see a line in the original programme which enables / disables VBAT but I can't fathom where the RTC oscillator is set to use SOSC rather than the internal clock.
thanks again .. Ash
The SOSC is set in the library. As the is called automatically this is set for you.
INTOFF Wait 1 s 'Wait stabilisation RTCCON.rtccLKSEL0 = 0 'POR Default RTCCON.rtccLKSEL1 = 0 'POR Default RTCCON.RTCWREN = 1 'MUST Write this bit before RTCEN Wait 100 ms 'Wait for SOSC to stabilise``I do remember having major issues. (But, I have lots of open Microchip tickets). And, it was with the CAPS and keeping the external clock source operational. Just cannot remember how I resolved.
Check back later in the week - meanwhile check the caps, your VBAT connection.
BUT! what version of Great Cow BASIC? What are you using to compile and link? Are you on the latest version and using Great Cow BASIC to compiler and generate your Hex?
@Ash. I am experiencing the same issue. I was incorrect. Unless you have fixed... I think we have an issue.
My finding. The RTCC operates as expected butthe following issues are happending.
Notes: #1.
- RTCC is operating once RTCSYNC = 1.
- From oscilloscope examination the crystal clock is taking ~10seconds to stablise.
Note: #2
- When power is removed from main circuit the RTCC stops.
- When power is removed from main circuit the current draw on VBAT is ~3ma.
- When power is removed from the main circuit the clock crystal stops oscillating. There is NO recovery from this situation.
Note: #3
- When power is restored to main circuit the RTCC restarts with 5 secs added to the last viewed time.
Same with your solution? Anything to add?
I have re-opened the Ticket with Microchip. I truly thought this was working.
@Ash. Fix #1
In the .h library, insert at line 104 the following - this will resolve one issue of the slow start up of the crystal clock and set the SOSC power correctly. This will not resolve the VBAT issue.
And, change the config in the main program as follows:
With these changes the RTCC clock works as expected. This is not clear by using the datasheet! You were totally correct that we needed to select SOSC as the clock source.
I think you will have to sort the brown-out event, like reseting the LCD etc etc - hopefully the VBAT event sets a bit somewhere as The I2C bus and the LCD will get reset by the power out (if you use the demo that is).
Let me know how you get on. Sorry for the delay and not getting the SOSC correct.
Last edit: Anobium 2018-06-19
"RSTOSC=SOSC" will set the primary clock (FOSC) to 32.768KHz and should not be necessary for RTC operation. The secondary oscillator (SOSC) should operate independantly from the main clock (FOSC).
Seems to me that you would want to enable the secondary oscillator after FOSC has stabilized. Then enable the RTC. I do not have this chip on hand but this is how I would try to do it, assuming that the internal clock source is used for FSOSC.
Last edit: William Roth 2018-06-19
@Bill. I was willing to try, I just did, but that config fails.. The clock fails when main power is removed.
I went through a lot of testing yesterday, and, I am with you regarding the RSTOSC. Hence, opening a ticket on this - I had lots of issues with this part when I got on test last year and all to do with the RTCC. Waits are needed, I found an issue with the LPBOREN and a lack of good examples.
Anyway, I did try. I thought you had cracked it. :-)
From Page 6 of the Errata ....
Is it the config that is incorrect or something else? Before concluding a bad or incorrect config, I would do the following to help narrow down the problem. Is it the SOSC ot RCT not starting or something else?
Check that the SOSC is running when set manually by checking the state of SOR bit In OSCSTAT. If SOR bit is set then SOSC should be running.
IF SOSC is not starting, the set SOSCPWR to 0 and test again. On other Chips with SOSC I have fond that 10 - 12 nF caps work well with clock crystals.
Try using MFINTOSC as the RTC Clock source (as a test) by setting MFOEN bit in OSCEN and setting RTCCLKSEL1 in RTCCON
Per Note above, poll the RTCEN bit to see it it is ever being set.
If this is only an issue with SOSC/RTC not operating with VBAT and backup battery then disregard the above. Let Microchip resolve it.
Last edit: William Roth 2018-06-19
Cheers.
The libary has addresses the delay etc. SOSC is starting - the clock is runnng.
The issue the SOCS/RTCC is not operating when using VBAT.
The resolution I posted works - I want Microchip to support or disprove. :-)
Thanks for all of your efforts everyone. I just got back to work today, so I am trying everthing suggested. I guess from your comments that we now need to wait for Microchip to respond. I don't mind waiting for their responce and hopefully the loss of clock on power-down can be fixed.
@Ash. This is the fix. https://sourceforge.net/p/gcbasic/discussion/579126/thread/8ea6a50e/#2440/03e5
Sorry for confusing you.
Hi .. I tried the fix but it still doesn't retain corect time on power cycling. In the Dropbox link below I included your code, suitably modified for my serial LCD setup and input buttons and the modified .h header file. I also videoed the clock setup (in the link) to show system powered down and losing it's settings along with a scope trace of the RC0 pin, which displays a steady 32.768kHz on RA5 until the main power is lost. The other trace on the scope is the VBAT input (RA5) , which shows a constant 4 VDC but the clock is lost on power down, despite the VBAT pin having 4v on it constantly. Or have I misunderstood and we are waiting for a suggested fix from Microchip for this?
Thanks again for all of your kind help and the recommedation of this really powerful, inexpensive and versatile chip (PIC16F19156)
https://www.dropbox.com/sh/0dlhhp6hwf80aq2/AACOEDbdemBCr-0E6TdA_4Rga?dl=0
Last edit: ashimotok0 2018-06-25
P.S. I used a main clock setup of 16 (as suggested by William) as I assumed that the secondary oscillator is merely that of the added crystal's frequency (I.e. 32.768 kHz )
I tried an experiment ...I removed the external crystal and made sure that the clock stopped incrementing ....which it did. This proves to me that the clock is indeed using the SOSC now, so it's just the VBAT issue I have now.
This is the same post as above. This works in terms of keeping the clock running. I have removed extra words.
@Ash. Fix #1
In the .h library, insert at line 104 the following - this will resolve one issue of the slow start up of the crystal clock and set the SOSC power correctly. This will not resolve the VBAT issue.
And, change the config in the main program as follows:
You were totally correct that we needed to select SOSC as the clock source.
This however is NOT a working solution - as I said when the main power is restored the event needs to captured and resolved. I have opened a ticket with Microchip as I cannot figure it out.
I have previously asked Microchip for an APPNOTE on the RTCC. I have just checked ny findings... same as last week and I still do not know how to resolve - we need Microchip.
Evan
Any news from Microchip please?
I have just chased them. Ticket is open. I also justed called support to chase - they 'should' call me back.
Not a lot we can do until they look at the issue.
News:
Microchip support did some tests on PIC16F19155 andthey succeded to obtain your required functionality using SOSC + DIVIDER=2. They provided a project to the case (testPIC16F19156_RTCC.X.zip).
They configured the device for starting using SOSC then in the software I switched the clock to HFINTOSC (32Mhz).
The project is MCC based so, they used different routines to re-configure clock and UART.
For testing they used the following pins: CLKOUT, RC3(RTCC), RC4(UART TX). The UART baudrate is 300 bps.
I compiled and tested.
Result of the tests was a fail.
My response:
Thank you.
Did you test on real hardware? I compiled etc. All good for that.
Yes the clock runs. When I remove the power, with VBAT attached, clock stops. This is the error I am trying to resolve.
See this video for the issue. https://www.dropbox.com/s/rz7chntrlbw0b34/RTCCError001.avi?dl=0
Need to sorted please, ASAP.
Anyone got a view?
I am being told Microchump. The RTCC when the main VCC is removed will only keep the time at the point of power off with VBAT powered. When main VCC is restored the RTCC with continue from where is left off. Therefore, a 10s power cut will cause the clock to loose 10s.
Tell me this is bonkers! Madness!!
Surely, the RTCC when the main VCC is removed will keep the time whilst the VBAT is powered. And, when RTCC is restores RTCC will still be correct.
Anyone got a view?
Sounds like buck passing to me.
What is the Point of having a Vbat connection that fails to act as a Vbat?
It is marketed as containing an RTC not Battery Backed SRAM.
I will pull down the data sheet and see how it is meant to work, but I doubt the datasheet says it only preserves the RAM and not the Clock.
Cheers
Chris