RTC S5D9

 Hello Team;

 

In our application we are using the RTC of the S5D9

We  use the same crystal as is used on the PK-S5D9: ABS07-32.768KHZ-T, also with 2 12pF load capacitors.

At Vbat we connected a 3V battery.

SODRV1=0 (standard mode 12,5pF)

When turning off the board voltage and turning it on 3 days later the RTC is about 30 seconds ahead.

The RTC is running 130ppm too fast.

During my test the PCB was turned off so I don't expect the problem to be caused by EMC phenomena.

I monioired the system for a few days and the delta stayed about 130ppm.

 What can be the problem and how can I solve this problem without using the Time Error Adjustment Function?

I don't want to use this function for now, because at this moment I do not know if this problem is reproducible on other PCB's.

With kind regards;

Pieter

 

 

  • Pieter,
    The fact that the RTC is running fast can only be if the sub-clock (and oscillator circuit) is running fast. However, from the data sheet the accuracy of the crystal is typically 10 to 30ppm. I am assuming all of your tests are at room temp, not at -40 / +85?
    Therefore, is the crystal and the sub clock oscillator stable?
    What is the stabilisation time you are allowing when you first turn on the sub clock?
    32.768kHz clocks do have a very long stabilisation time.
    I typically allow at least 2 seconds from turning on the sub clock to actually using it.
    Is this the issue?
    If the oscillator circuit has not had chance to fully stabilise, is it running on a strange harmonic that results in faster operation?
    If we can eliminate this then we can can move on to other reasons.
    Regards,
    Richard
  • In reply to Richard:

    Hi Richard;

    The stabilisation time in our application is not as long as 2 seconds.
    I'm waiting for a colleague (software engineer) to extend this time.
    I will reply if this has solved the problem.

    Regards;
    Pieter
  • In reply to Pieter:

    Using ssp version 1.6.x.
    In r_rtc.c function r_rtc_set_clock_source() the stabilization delay after setting the sub-clock is only 100 milliseconds.
    Why not variable?
  • In reply to J A:

    The delay you refer to is to satisfy this condition of the RTC:

     

     

    The BSP does not by default offer any stabilisation time for the subclock.

    This can be "fixed" with this work around:

    Add this C file

    user_warm_start.txt
    /*
     * user_warm_start.c
     *
     *  Created on: 1 Feb 2018
     *      Author: a5015980
     */
    #include "hal_data.h"
    
    
    void R_BSP_WarmStart (bsp_warm_start_event_t event);
    
    
    void R_BSP_WarmStart (bsp_warm_start_event_t event)
    {
        if (BSP_WARM_START_PRE_C == event)
        {
            /* C runtime environment has not been setup so you cannot use globals. System clocks and pins are not setup. */
    
            /* wait some time to ensure SOSTP bit is valid */
            for(uint32_t long_delay=0; long_delay < 50; long_delay++)
            {
                __NOP();
            }
    
            /* Check - is the sub clock running? */
            if( 1 == R_SYSTEM->SOSCCR_b.SOSTP )
            {
                R_SYSTEM->PRCR = 0xa501;
    
                R_SYSTEM->SOSCCR_b.SOSTP = 0;   /* turn on the sub clock */
                R_SYSTEM->PRCR = 0xa500;
    
                /* wait for 2 seconds for the sub clock to stabilise */
                /* At this point the device is running on running on the 8MHz/16  = 500kHz MOCO */
                for(uint32_t long_delay=0; long_delay<142854; long_delay++)     /* from measurement: 142854 __NOP() loop  == 2s */
                {
                    __NOP();
                }
            }
        }
        else if (BSP_WARM_START_POST_C == event)
        {
            /* C runtime environment, system clocks, and pins are all setup. */
        }
        else
        {
            /* Do nothing */
        }
    }
    

     (uploaded as .txt file) to your project and configure the "Subclock Drive On Reset" option set to Disabled.

     

     

     

    By default  R_BSP_WarmStart is a weakly defined function, so the code in user_warm_start.c will overwrite it.

    void R_BSP_WarmStart (bsp_warm_start_event_t event) is the first functioned called once the PC and SP are initialised.

    The function checks to see if the Subclock is running.

    If it isn’t, then it is started with a stabilisation time.

    I typically allow 2 seconds for the sub clock to stabilise.

    This will only happen on Power On Reset.

     

    If needed, the subclock drive strength could be set in this function too.

     

    As the sub-clock will continue to operate in low power modes and via reset's, this stabilisation process should only ever run on Power On Reset.

     

    Regards,

     

  • In reply to Richard:

    If you are interested, please find attached a S5D9_PK project that will configure the RTC to operate on the Sub-Clock on a Power On reset. 

    This application uses a modified version of user_warm_start.c  that I posted earlier.

     

    All other resets will not try to reconfigure the sub-clock and RTC which means that the RTC will continue to run uninterrupted whilst power is applied to the PK board.

    The application is written for the S5D9-PK.

    On a Power On Reset, LED3 (Amber LED) will turn on.

    On a Pin Reset, LED2 (Red LED) will toggle and turn on.

    On a Software Reset (software reset is generated by the JLink debugger) the LEDs will be turned off.

    Pressing S5 will enable / disable the RTC periodic interrupt and will toggle LED1 (green LED)

    If enabled then this interrupt will continue operate after the Pin Reset and Software Resets.

     

    Thought this may be of interest

    Regards,

     

    S5D9_PK_RTC_with_Reset.zip

  • In reply to Richard:

    2 seconds stabilisation time implemented.
    The RTC is still 10 seconds too fast in 24 hours!!!
  • In reply to J A:

    Hello J A

    I've done some additional investigation into this and I think I may have an answer.


    You mention in your original post that you have the same crystal and values of capacitor as the  "PK-S5D9: ABS07-32.768KHZ-T, also with 2 12pF load capacitors."
    I need to verify this with the chip designers but I believe that the 12pF capacitors on the sub clock circuit are too low.

    The Hardware User's Manual shows this circuit for the sub clock

    I believe that the relationship of C1 and C2 to CL should be considered as:

    where Cs is stray capacitance of the board.

     

    In which case, if C1 and C2 = 12pF, and we assume Cs = 2~3pF, then CL = 8pF~9pF

    From the data sheet this is too low.

    If we fit C1 and C2 = 22pF, then CL = 13pF~14pF, which is in line with the data sheet.

    This is what I have done on the PK board. I have fitted 22pF capacitors.

    I have not done a 24 hour soak test, but I have measured the effect on the 64Hz RTC Clock Out signal on P4.7

    With C1 , C2 = 12pF then RTC Clock Out = 64.00600Hz. I calculate this would equal an error of 8.1 seconds on 24hours.  Similar to what you were seeing.

    With C1 , C2 = 22pF then RTC Clock Out = 64.00120Hz, I calculate this would equal an error of 1.6 seconds on 24hours.

    Could you therefore please change you capacitor values to 22pF and see if that increases the accuracy of the RTC

     

    Regards,

    Richard

  • Hi Richard,

    You are right about the general calculus of C1 and C2 in function of CL, but I've checked the value of these capacitors on several reference designs (including circuits of your partners) and the value is 12pF in all cases! maybe this is an inherited error.
    I think your HW department have to confirm this because a lot of engineers take the values of this kind of components as a base of our designs and these mistakes make us crazy.

    BR,
    Víctor.
  • In reply to Richard:

    Thank you Richard;

    We came to the same conclusion.
    We changed C1,2 into 22pF. After 22 hours the the error is about 0 (zero) seconds.

    In your calculation; what is the stray capacitance of 2~3pF based on?
    Is it also based on the in- and output capacitance of Xcin, Xcout. I can't find these values in the datasheet.


    Regards;
    Pieter
  • In reply to Pieter:

    Hi Pieter,

    These 2~3pF are empirical and are due to the parasitic capacities existing in the XTAL inputs and the tracks of the pcb.

    BR,
    Víctor