Can't set the HW clock on armStoneA5 Board Rev. 1.10 with rootfs_std-fsvybrid-V2.1

    The HW-clock on my Vybrid Armstone A5 PCB does not accept a date.


    I set the date with
    # date "2016-07-03 18:54"
    -> Sun Jul 3 18:54:00 UTC 2016
    and then setting the HW clock fails with
    # hwclock --systohc
    -> rtc-pcf8563 3-0051: pcf8563_set_datetime: err=-5 addr=02, data=06
    -> hwclock: RTC_SET_TIME: Input/output error


    In the past this forum mentions issues like
    -RTC not working at all or
    -high power consumption, thus using an external HW clock chip instead of the internal one.
    However, I do not know how to resolve this issue.


    Below the boot messages:


    Linux version 3.0.15-F+S (keller@VBFedora14) (gcc version 4.7.2 (crosstool-NG 1.18.0 - for F+S boards and modules) ) #1 Fr4
    CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d
    CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
    Machine: F+S Elektronik Systeme GmbH, armStoneA5


    armStoneA5 Board Rev. 1.10


    rtc-pcf8563 3-0051: chip found, driver version 0.4.3
    rtc-pcf8563 3-0051: pcf8563_get_datetime: read error
    rtc-pcf8563 3-0051: rtc core: registered rtc-pcf8563 as rtc0
    snvs_rtc snvs_rtc.0: rtc core: registered snvs_rtc as rtc1


    Welcome to F+S-Vybrid
    fsvybrid login: root
    # uname -a
    ->Linux fsvybrid 3.0.15-F+S #1 Fri Aug 22 09:50:12 CEST 2014 armv7l GNU/Linux

    A hint by F&S could bring a bit light into this issue!
    The correct rtc to use for the Vybrid (my PCB from 2013) is /dev/rtc1 and not /dev/rtc0!


    Thus you can set the HW Clock with, e.g.,
    #date "2016-07-04 22:37"
    #hwclock --systohc --rtc=/dev/rtc1 /* set HW clock to current system time */
    #hwclock -r --rtc=/dev/rtc1 /* read HW clock */


    Now date/time "survives" a reboot.


    However, when unplugging from power the Vybrid-A5 looses date/time.
    According to F&S this hardware issue is resolved with recent Vybrid-A5.

    The correct way to set the time would be to write it to every available rtc device.

    Code
    1. for rtc in /dev/rtc?
    2. do
    3. hwclock --systohc --rtc=$i
    4. done


    The reason for this is that you can not tell for sure which clock will get which rtc number. Linux enumerates the rtc devices in the order they are registered at start-up. But this order is rather random and currently depends on the order the driver modules were built during compilation, which in turn depends on the module file names or the order the modules appear in the makefile. So simply recompiling the code or modifying something simple in the makefile can lead to a different order of the RTC clocks at runtime. So it is better to set the time to all available hardware clocks. At startup, our Linux checks both RTC devices and takes the first value that looks like a valid date/time.


    The reason for having two RTCs in the Vybrid environment at all originates from the fact that early Vybrid CPUs had a hardware bug where the internal RTC drew too much current from the standby power, which meant that a battery was empty in about a week or two. So for example on PicoCOMA5 we added an optional external RTC (via I2C) and did not use the internal RTC for a while. Current CPU revisions do not have this silicon bug anymore, so we have dropped the external RTC and use the internal RTC again. However the RTC code on our boards is designed in a way that it will work with either RTC configuration, as long as you write the time to both RTC devices. However if you feel uncomfortable with this behavior, you can now savely remove the driver of the external RTC (Device drivers -> Real Time Clock -> Philips PCF8563/Epson RTC8564), because all boards that are shipped now and in the future will have a working internal RTC. So problems can only exist on very early development boards, but not on boards shipped for the series.


    Regarding the time loss when power is switched off. This is strange. The time should always be kept if VBat is supplied on the power connector, for example by using a coin cell. This was even true with the broken Vybrid chip revision. Back then the battery was only empty rather soon. Now with the new chip revision, the standby current is in the micro-ampere region and a Lithium coin cell should stay alive for several years.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    I did a retest and found the same result: When powering off date/time are gone.
    I use adapter
    https://www.fs-net.de/de/produ…r/armstone-power-adapter/
    with a cell 2032 (3V).
    I just measured the off-load cell voltage (Vybrid module is disconnected) at J4 Pin 1/2 and 5/6: 2.6V
    When connecting the Vybrid module it drops down to 1.7V.
    The table below shows the figures completed by the voltage measured directly at the inserted CR2032.


    Code
    1. Connection state
    2. Power Adapter /
    3. Vybrid module J4 CR2032
    4. ----------------------------------------
    5. unplugged 2,6V 2,7V
    6. plugged 1,7V 2,65V


    To repeat: I measure a voltage drop at J4 from 2.6 down to 1.7V. I did this with another cell with similar results.
    The voltage drop of 0.9V might be to high and the 1.7V are insufficient to maintain date/time.


    Below are the lines from the boot log related to Vybrid Revision.
    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
    Uncompressing Linux... done, booting the kernel.
    Linux version 3.0.15-F+S (keller@VBFedora14) (gcc version 4.7.2 (crosstool-NG 1.18.0 - for F+S boards and modul4
    CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d
    CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------


    [Edit fs-support_HK: Fixed the Table]

    Quote from rdohmhardt

    I just measured the off-load cell voltage (Vybrid module is disconnected) at J4 Pin 1/2 and 5/6: 2.6V


    This means that the coin cell is not the newest anymore.


    Quote

    When connecting the Vybrid module it drops down to 1.7V.


    Is this with regular power on or off? When main power is on, then the drop should not happen. Your CPU is in fact the revision with the RTC bug. So if main power is off, then the standby current is in the milli-ampere region (instead of micro-ampere), so a considerable voltage drop on the internal Schottky diode of the 24V adapter board is to be expected.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.