marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

I2C RTC wipe/corruption on new kernel boot?

Sun Feb 08, 2015 2:10 am

Hi Everyone

I've been using a DS3231 RTC on my Pis with no issue at all. It's the equivalent of a DS1307 except the crystal is internal and the accuracy is something like +-1second a month vs the good old ds1307 at +-2 minutes a day!

I have been using this setup for over a year now with 100% reliability and no sudden surprises.

On my B+ and Pi2 on updating to the most recent kernel, via both a re-image and rpi-update I am getting a very weird behavior which is completely reproducible.

Summary:
1. Device instantiated correctly according to dmesg.
2. Set the time with hwclock -w: all good.
3. Read the time with hwclock -r: all good, as many times as you want.
4. Reboot.
5. Read the time with hwclock -r: Invalid values in hardware clock: 2066/01/01 00:01:40
6. Re-read etc it's never fixed, but the seconds/minutes go up, so the clock is being read and is active.
7. Write with hwclock -w
8. Read with hwclock -r: the time is now correct.

I have multiple spares of the clock pcb which has a soldered-on battery, and here's the clincher for this test:
1. Write the time to both via hot-swap: all good.
2. Verify both via hot-swap: all good.
3. Reboot Pi.
4. Read the time back: FAIL. Invalid values in hardware clock: 2066/01/01
5. Hot swap to other module that was unplugged during reboot.
6. Read time:Time reads OK with correct time.
7. Reboot Pi.
8. Read the time back: FAIL. Invalid values in hardware clock: 2066/01/01.

So, from my perspective I've eliminated the cable, the RTC module etc. It all seems to be down to the kernel changes in recent versions.

Sadly I don't have a dual trace oscilloscope, so it's a bit hard to go down to the wire.

Am I the only person experiencing this?

Logs and dmesg attached, and a photo of the wiring...

Code: Select all

############## Set the clocks
[email protected]:~# hwclock --debug -w
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1423352224 seconds after 1969
Last calibration done at 1423352224 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2015/02/07 23:37:23
Hw clock time : 2015/02/07 23:37:23 = 1423352243 seconds since 1969
Time elapsed since reference time has been 0.503966 seconds.
Delaying further to reach the new time.
Setting Hardware Clock to 23:37:24 = 1423352244 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because it has been less than a day since the last calibration.

[email protected]:~# hwclock --debug -w
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1423352243 seconds after 1969
Last calibration done at 1423352243 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2015/02/07 23:37:36
Hw clock time : 2015/02/07 23:37:36 = 1423352256 seconds since 1969
Time elapsed since reference time has been 0.504680 seconds.
Delaying further to reach the new time.
Setting Hardware Clock to 23:37:37 = 1423352257 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because it has been less than a day since the last calibration.
[email protected]:~#




##############  read the clock: both clocks OK
[email protected]:~# hwclock -r --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1423352256 seconds after 1969
Last calibration done at 1423352256 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2015/02/07 23:38:11
Hw clock time : 2015/02/07 23:38:11 = 1423352291 seconds since 1969
Sun 08 Feb 2015 09:38:11 AEST  -0.531360 seconds
[email protected]:~#


[email protected]:~# hwclock -r --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1423352256 seconds after 1969
Last calibration done at 1423352256 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2015/02/07 23:38:36
Hw clock time : 2015/02/07 23:38:36 = 1423352316 seconds since 1969
Sun 08 Feb 2015 09:38:36 AEST  -0.524679 seconds
[email protected]:~#




######## reboot with rtc plugged in, then read : corrupt values
[email protected]:~# hwclock -r --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1423352335 seconds after 1969
Last calibration done at 1423352335 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2066/01/01 00:01:40
Invalid values in hardware clock: 2066/01/01 00:01:40
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).
[email protected]:~#


####swap rtc: correct values
[email protected]:~# hwclock -r --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1423352335 seconds after 1969
Last calibration done at 1423352335 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2015/02/07 23:41:08
Hw clock time : 2015/02/07 23:41:08 = 1423352468 seconds since 1969
Sun 08 Feb 2015 09:41:08 AEST  -0.171290 seconds
dmesg:

Code: Select all

[email protected]:~# dmesg
[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.18.5-v7+ ([email protected]) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #748 SMP PREEMPT Wed Feb 4 21:33:52 GMT 2015
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Raspberry Pi 2 Model B
[    0.000000] cma: Reserved 8 MiB at 0x3a800000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 241664
[    0.000000] free_area_init_node: node 0, pgdat 80820440, node_mem_map ba093000
[    0.000000]   Normal zone: 1888 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 241664 pages, LIFO batch:31
[    0.000000] [bcm2709_smp_init_cpus] enter (8620->f3003010)
[    0.000000] [bcm2709_smp_init_cpus] ncores=4
[    0.000000] PERCPU: Embedded 11 pages/cpu @ba05d000 s12864 r8192 d24000 u45056
[    0.000000] pcpu-alloc: s12864 r8192 d24000 u45056 alloc=11*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 239776
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa21041 bcm2709.serial= smsc95xx.macaddr= bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 940740K/966656K available (5785K kernel code, 377K rwdata, 1760K rodata, 396K init, 771K bss, 25916K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xbb800000 - 0xff000000   (1080 MB)
[    0.000000]     lowmem  : 0x80000000 - 0xbb000000   ( 944 MB)
[    0.000000]     modules : 0x7f000000 - 0x80000000   (  16 MB)
[    0.000000]       .text : 0x80008000 - 0x8076670c   (7546 kB)
[    0.000000]       .init : 0x80767000 - 0x807ca000   ( 396 kB)
[    0.000000]       .data : 0x807ca000 - 0x808287ac   ( 378 kB)
[    0.000000]        .bss : 0x808287ac - 0x808e9694   ( 772 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:480
[    0.000000] Architected cp15 timer(s) running at 19.20MHz (virt).
[    0.000013] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 3579139424256ns
[    0.000037] Switching to timer-based delay loop, resolution 52ns
[    0.000330] Console: colour dummy device 80x30
[    0.001756] console [tty1] enabled
[    0.001808] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[    0.001892] pid_max: default: 32768 minimum: 301
[    0.002309] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.002369] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.003677] Initializing cgroup subsys memory
[    0.003762] Initializing cgroup subsys devices
[    0.003816] Initializing cgroup subsys freezer
[    0.003867] Initializing cgroup subsys net_cls
[    0.003932] Initializing cgroup subsys blkio
[    0.004046] CPU: Testing write buffer coherency: ok
[    0.004162] ftrace: allocating 19967 entries in 59 pages
[    0.053523] CPU0: update cpu_capacity 1024
[    0.053601] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
[    0.053640] [bcm2709_smp_prepare_cpus] enter
[    0.053801] Setting up static identity map for 0x5368b8 - 0x536910
[    0.113466] [bcm2709_boot_secondary] cpu:1 started (0) 17
[    0.113783] CPU1: Booted secondary processor
[    0.113791] [bcm2709_secondary_init] enter cpu:1
[    0.113845] CPU1: update cpu_capacity 1024
[    0.113854] CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
[    0.133444] [bcm2709_boot_secondary] cpu:2 started (0) 17
[    0.133686] CPU2: Booted secondary processor
[    0.133693] [bcm2709_secondary_init] enter cpu:2
[    0.133724] CPU2: update cpu_capacity 1024
[    0.133733] CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
[    0.153510] [bcm2709_boot_secondary] cpu:3 started (0) 16
[    0.153735] CPU3: Booted secondary processor
[    0.153742] [bcm2709_secondary_init] enter cpu:3
[    0.153773] CPU3: update cpu_capacity 1024
[    0.153781] CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
[    0.153872] Brought up 4 CPUs
[    0.153993] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[    0.154027] CPU: All CPU(s) started in SVC mode.
[    0.155076] devtmpfs: initialized
[    0.178175] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
[    0.180371] pinctrl core: initialized pinctrl subsystem
[    0.183382] NET: Registered protocol family 16
[    0.189000] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[    0.213297] cpuidle: using governor ladder
[    0.243326] cpuidle: using governor menu
[    0.243725] bcm2709.uart_clock = 3000000
[    0.246899] No ATAGs?
[    0.246966] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.247022] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.247085] mailbox: Broadcom VideoCore Mailbox driver
[    0.247216] bcm2708_vcio: mailbox at f300b880
[    0.247325] bcm_power: Broadcom power driver
[    0.247358] bcm_power_open() -> 0
[    0.247384] bcm_power_request(0, 8)
[    0.748089] bcm_mailbox_read -> 00000080, 0
[    0.748120] bcm_power_request -> 0
[    0.748288] Serial: AMBA PL011 UART driver
[    0.748445] dev:f1: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev3
[    1.266685] console [ttyAMA0] enabled
[    1.346732] SCSI subsystem initialized
[    1.350757] usbcore: registered new interface driver usbfs
[    1.356425] usbcore: registered new interface driver hub
[    1.361887] usbcore: registered new device driver usb
[    1.368839] Switched to clocksource arch_sys_counter
[    1.403535] FS-Cache: Loaded
[    1.406781] CacheFiles: Loaded
[    1.422335] NET: Registered protocol family 2
[    1.427974] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    1.435226] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    1.441931] TCP: Hash tables configured (established 8192 bind 8192)
[    1.448403] TCP: reno registered
[    1.451680] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    1.457665] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    1.464425] NET: Registered protocol family 1
[    1.469288] RPC: Registered named UNIX socket transport module.
[    1.475231] RPC: Registered udp transport module.
[    1.480018] RPC: Registered tcp transport module.
[    1.484740] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.492277] bcm2708_dma: DMA manager at f3007000
[    1.497082] vc-mem: phys_addr:0x00000000 mem_base=0x3dc00000 mem_size:0x3f000000(1008 MiB)
[    1.507057] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    1.513518] audit: initializing netlink subsys (disabled)
[    1.519031] audit: type=2000 audit(1.309:1): initialized
[    1.540748] VFS: Disk quotas dquot_6.5.2
[    1.545064] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.554756] FS-Cache: Netfs 'nfs' registered for caching
[    1.561140] NFS: Registering the id_resolver key type
[    1.566267] Key type id_resolver registered
[    1.570496] Key type id_legacy registered
[    1.575640] msgmni has been set to 1853
[    1.581281] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    1.588957] io scheduler noop registered
[    1.592910] io scheduler deadline registered (default)
[    1.598374] io scheduler cfq registered
[    1.604914] BCM2708FB: allocated DMA memory fac00000
[    1.609978] BCM2708FB: allocated DMA channel 0 @ f3007000
[    1.621796] Console: switching to colour frame buffer device 82x26
[    1.634118] bcm2708-dmaengine bcm2708-dmaengine: Load BCM2835 DMA engine driver
[    1.643461] uart-pl011 dev:f1: no DMA platform data
[    1.650544] vc-cma: Videocore CMA driver
[    1.656048] vc-cma: vc_cma_base      = 0x00000000
[    1.662325] vc-cma: vc_cma_size      = 0x00000000 (0 MiB)
[    1.669272] vc-cma: vc_cma_initial   = 0x00000000 (0 MiB)
[    1.688057] brd: module loaded
[    1.698768] loop: module loaded
[    1.703706] vchiq: vchiq_init_state: slot_zero = 0xba800000, is_master = 0
[    1.712886] Loading iSCSI transport class v2.0-870.
[    1.720252] usbcore: registered new interface driver smsc95xx
[    1.727575] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    1.935237] Core Release: 2.80a
[    1.939894] Setting default values for core params
[    1.946169] Finished setting default values for core params
[    2.153642] Using Buffer DMA mode
[    2.158427] Periodic Transfer Interrupt Enhancement - disabled
[    2.165803] Multiprocessor Interrupt Enhancement - disabled
[    2.172931] OTG VER PARAM: 0, OTG VER FLAG: 0
[    2.178865] Dedicated Tx FIFOs mode
[    2.184252] WARN::dwc_otg_hcd_init:1047: FIQ DMA bounce buffers: virt = 0xbac14000 dma = 0xfac14000 len=9024
[    2.197215] FIQ FSM acceleration enabled for :
[    2.197215] Non-periodic Split Transactions
[    2.197215] Periodic Split Transactions
[    2.197215] High-Speed Isochronous Endpoints
[    2.220102] dwc_otg: Microframe scheduler enabled
[    2.220168] WARN::hcd_init_fiq:412: FIQ on core 1 at 0x803e3ea8
[    2.227715] WARN::hcd_init_fiq:413: FIQ ASM at 0x803e4204 length 36
[    2.235623] WARN::hcd_init_fiq:438: MPHI regs_base at 0xbb806000
[    2.243260] dwc_otg bcm2708_usb: DWC OTG Controller
[    2.249766] dwc_otg bcm2708_usb: new USB bus registered, assigned bus number 1
[    2.258626] dwc_otg bcm2708_usb: irq 32, io mem 0x00000000
[    2.265748] Init: Port Power? op_state=1
[    2.271227] Init: Power Port (0)
[    2.276245] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.284648] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.293465] usb usb1: Product: DWC OTG Controller
[    2.299732] usb usb1: Manufacturer: Linux 3.18.5-v7+ dwc_otg_hcd
[    2.307290] usb usb1: SerialNumber: bcm2708_usb
[    2.314353] hub 1-0:1.0: USB hub found
[    2.319763] hub 1-0:1.0: 1 port detected
[    2.325655] dwc_otg: FIQ enabled
[    2.325670] dwc_otg: NAK holdoff enabled
[    2.325682] dwc_otg: FIQ split-transaction FSM enabled
[    2.325721] Module dwc_common_port init
[    2.326101] usbcore: registered new interface driver usb-storage
[    2.333921] mousedev: PS/2 mouse device common for all mice
[    2.341671] bcm2835-cpufreq: min=600000 max=900000
[    2.348301] sdhci: Secure Digital Host Controller Interface driver
[    2.356069] sdhci: Copyright(c) Pierre Ossman
[    2.362187] DMA channels allocated for the MMC driver
[    2.398885] Load BCM2835 MMC driver
[    2.405704] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.414613] ledtrig-cpu: registered to indicate activity on CPUs
[    2.427720] hidraw: raw HID events driver (C) Jiri Kosina
[    2.435048] usbcore: registered new interface driver usbhid
[    2.443304] usbhid: USB HID core driver
[    2.452164] TCP: cubic registered
[    2.458110] Initializing XFRM netlink socket
[    2.464027] NET: Registered protocol family 17
[    2.473520] Key type dns_resolver registered
[    2.479838] Registering SWP/SWPB emulation handler
[    2.487109] registered taskstats version 1
[    2.492973] vc-sm: Videocore shared memory driver
[    2.499190] [vc_sm_connected_init]: start
[    2.505372] [vc_sm_connected_init]: end - returning 0
[    2.512029] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.518998] Indeed it is in host mode hprt0 = 00021501
[    2.530888] Waiting for root device /dev/mmcblk0p2...
[    2.532199] mmc0: new high speed SDHC card at address e624
[    2.532826] mmcblk0: mmc0:e624 SU16G 14.8 GiB
[    2.534319]  mmcblk0: p1 p2
[    2.571571] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.582817] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    2.592219] devtmpfs: mounted
[    2.597436] Freeing unused kernel memory: 396K (80767000 - 807ca000)
[    2.698963] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    2.707371] Indeed it is in host mode hprt0 = 00001101
[    2.909267] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    2.917849] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.927839] hub 1-1:1.0: USB hub found
[    2.933575] hub 1-1:1.0: 5 ports detected
[    3.219087] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    3.339434] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    3.348488] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.361857] smsc95xx v1.0.4
[    3.423225] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet,
[    3.669189] udevd[175]: starting version 175
[    4.262697] bcm2708_spi 3f204000.spi: master is unqueued, this is deprecated
[    4.295931] bcm2708_spi 3f204000.spi: SPI Controller at 0x3f204000 (irq 80)
[    4.414944] bcm2708_i2c_init_pinmode(1,2)
[    4.445026] bcm2708_i2c_init_pinmode(1,3)
[    4.457869] bcm2708_i2c 3f804000.i2c: BSC1 Controller at 0x3f804000 (irq 79) (baudrate 100000)
[    5.692839] i2c i2c-1: new_device: Instantiated device ds1307 at 0x68
[    5.712491] rtc-ds1307 1-0068: rtc core: registered ds1307 as rtc0
[    5.722940] rtc-ds1307 1-0068: 56 bytes nvram
[    5.921047] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    6.135178] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    6.707936] i2c /dev entries driver
[   10.130943] random: dd urandom read with 122 bits of entropy available
[   10.623422] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   10.623948] random: nonblocking pool is initialized
[   12.082880] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1
[   12.729812] Adding 102396k swap on /var/swap.  Priority:-1 extents:2 across:2162644k SSFS
[email protected]:~#
Attachments
20150208_102318_rtc.jpg
20150208_102318_rtc.jpg (42.79 KiB) Viewed 12792 times


marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Sun Feb 08, 2015 4:52 am

Thanks for the reply but can you explain to me how a link to 'how to enable I2C with devicetree kernels' is going to help with memory corruption by the I2C driver?

I did hope that putting the line '1. Device instantiated correctly according to dmesg.' might have saved someone the effort of posting the above link when I already have that working. :)

Or have I missed something? I tried to debug this as much as possible before posting :(

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Sun Feb 08, 2015 3:46 pm

marcus15 wrote:
Thanks for the reply but can you explain to me how a link to 'how to enable I2C with devicetree kernels' is going to help with memory corruption by the I2C driver?

I did hope that putting the line '1. Device instantiated correctly according to dmesg.' might have saved someone the effort of posting the above link when I already have that working. :)

Or have I missed something? I tried to debug this as much as possible before posting :(
I apologize. I did not read carefully enough.

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Mon Feb 09, 2015 8:20 am

So I tried a few more things...
1. I set the RTC then yanked the power from the PI. On restart it had been wiped. So it's happening on the boot-up not the shutdown.
2. I changed my device instantiation line to the following:
echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
(it was: echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device).
Going by the kernel source code for the ds1307 module this should make no difference, but I tried it anyway.

Any of the RPi engineering gurus have any input? :)

The hunt continues....

Thanks!

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Mon Feb 09, 2015 8:50 am

More research...

If I don't instantiate the clock device, but leave it plugged in across reboots it *does not* get corrupted. I am checking with i2cdump:

Code: Select all

[email protected]:~# i2cdump  -y 1 0x68
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 42 47 08 02 09 82 15 00 00 00 00 00 00 00 1c 08    BG?????.......??
10: 00 1d 80 XX XX XX XX XX XX XX XX XX XX XX XX XX    .??XXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX 80 80 80 80    XXXXXXXXXXXX????
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2444
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: I2C RTC wipe/corruption on new kernel boot?

Mon Feb 09, 2015 9:30 am

So, to summarise, are you saying that the act of loading the driver module is corrupting the device? If so, how unfortunate.

1) Can you repeat the i2cdump test (nice idea), once after booting but before loading the module, and once after loading it? You can trim down the output to the first few lines.

2) At any point where you think you have the module loaded and the RTC programmed correctly, try rmmoding the module and i2cdumping, then modprobing and i2cdumping.

3) Try disabling Device Tree (device_tree=) - I don't expect this to make a difference, but there have been a few surprises.

I know these are close to things you've tried already, but it helps to minimise the number of steps involved.

Out of curiosity, are you using the overlay for the ds1307 (dtoverlay=ds1307-rtc) or using modprobe?

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Mon Feb 09, 2015 11:21 am

Answers in the most logical order...
PhilE wrote:Out of curiosity, are you using the overlay for the ds1307 (dtoverlay=ds1307-rtc) or using modprobe?
I was using the old style as listed in my last post in hwclock.sh. On your suggestion I added the devicetree string into config.txt and I can see it loading earlier in dmesg.txt but the clock is still corrupted.
PhilE wrote:1) Can you repeat the i2cdump test (nice idea), once after booting but before loading the module, and once after loading it? You can trim down the output to the first few lines.
Done.

Code: Select all

[email protected]pi:~# hwclock -w
[email protected]:~# hwclock -r
Mon 09 Feb 2015 20:47:40 AEST  -0.559181 seconds
[email protected]:~# reboot
[snip]
Linux quadpi 3.18.5-v7+ #748 SMP PREEMPT Wed Feb 4 21:33:52 GMT 2015 armv7l
Last login: Thu Jan  1 10:00:15 1970 from vmh.xlserv.som
[email protected]:~# hwclock -r
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.
[email protected]:~# i2cdump -y 1 0x68
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 29 48 10 02 09 02 15 00 00 00 00 00 00 00 1c 08    )H?????.......??
10: 00 1d 80 XX XX XX XX XX XX XX XX XX XX XX XX XX    .??XXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX 80 80 80 80    XXXXXXXXXXXX????
[email protected]:~# echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
[email protected]:~# rmmod rtc_ds1307
[email protected]:~# i2cdump -y 1 0x68
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 16 51 10 02 09 02 15 00 00 00 00 00 00 00 1c 08    ?Q?????.......??
10: 00 1d 80 XX XX XX XX XX XX XX XX XX XX XX XX XX    .??XXXXXXXXXXXXX
[email protected]:~# modprobe rtc_ds1307
[email protected]:~# hwclock -r
Mon 09 Feb 2015 20:51:54 AEST  -0.244369 seconds
[email protected]:~#
So the act of loading the module or instantiating the device post boot is *not* corrupting the clock.
PhilE wrote:2) At any point where you think you have the module loaded and the RTC programmed correctly, try rmmoding the module and i2cdumping, then modprobing and i2cdumping.

Code: Select all

[email protected]:~# hwclock -r
Mon 09 Feb 2015 20:54:41 AEST  -0.075738 seconds
[email protected]:~# rmmod rtc_ds1307
[email protected]:~# i2cdump -y 1 0x68
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 47 54 10 02 09 02 15 00 00 00 00 00 00 00 1c 08    GT?????.......??
10: 00 1d 40 XX XX XX XX XX XX XX XX XX XX XX XX XX    [email protected]
[email protected]:~# modprobe rtc_ds1307
[email protected]:~# hwclock -r
Mon 09 Feb 2015 20:55:17 AEST  -0.011493 seconds
[email protected]:~# rmmod rtc_ds1307
[email protected]:~# i2cdump -y 1 0x68
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 27 55 10 02 09 02 15 00 00 00 00 00 00 00 1c 08    'U?????.......??
10: 00 1d 40 XX XX XX XX XX XX XX XX XX XX XX XX XX    [email protected]
20: XX XX XX XX XX XX XX XX XX XX XX XX 40 40 40 40    [email protected]@@@
[email protected]:~# modprobe rtc_ds1307
[email protected]:~# hwclock -r
Mon 09 Feb 2015 20:55:40 AEST  -0.115985 seconds
[email protected]:~#
Just loading/unloading does not seem to corrupt it.
PhilE wrote:3) Try disabling Device Tree (device_tree=) - I don't expect this to make a difference, but there have been a few surprises.
OK so I tested this and the result is no different.
1. I added the modules etc into auto-load
2. hwclock.sh had everything that does anything except 'echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device' removed.
3. Reboot
4. Same result: clock corrupt

It seems to me that something early in the boot process is corrupting the clock considering that if it's loaded either via devicetree or modprobe early in the boot process (4-6 seconds going via the dmesg timestamps) it's corrupted, but if it's loaded after the first boot there does not seem to be any corruption.

I've tried grepping for hwclock through /etc and nothing looked suspicious. If only I could make it log all calls to rtc to syslog this would probably be solved very quickly... I can dream. I'm not sure how to get strace style logs that early in the boot.

I've removed the fake-hwclock package and one cron script that seemed to be left over from it in case they were causing problems. Anything else to be on the lookout for?

If you want to have a gander at it let me know and I'll set up a VLAN and firewall it off and give you a tunnel through to it, but in all honesty I want to beat this b****** myself :)

Thanks for looking at this issue!

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Tue Feb 10, 2015 10:10 am

OK so after a day of trying many different things (I tried disabling everything that plays with the clock and then reintroduced them) which I won't bother listing I have discovered something: if I disable ntp (the daemon) the clock does not get corrupted.

Code: Select all

[email protected]:~# hwclock -r
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).
[email protected]:~# hwclock -w
[email protected]:~# update-rc.d ntp disable
update-rc.d: using dependency based boot sequencing
insserv: warning: current start runlevel(s) (empty) of script `ntp' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ntp' overrides LSB defaults (empty).
[email protected]:~# hwclock -r
Tue 10 Feb 2015 19:28:29 AEST  -0.260247 seconds
[email protected]:~# reboot
[snip]
[email protected]:~# hwclock -r
Tue 10 Feb 2015 19:29:07 AEST  -0.684258 seconds
[email protected]:~#
All good!

Now I disable ntpdate to see if the clock is actually being set:

Code: Select all

[email protected]:~# mv /usr/sbin/ntpdate /usr/sbin/ntpdate.disabled
[email protected]:~# date
Tue Feb 10 19:30:28 AEST 2015
[email protected]:~# reboot
[snip]
[email protected]:~# date
Thu Jan  1 10:00:23 AEST 1970
[email protected]:~# hwclock -r
Tue 10 Feb 2015 19:32:29 AEST  -0.708158 seconds
[some time elapses]
OK I solved it!
I added a set -x to hwclock.sh then ran it. It bombed out on this:
++ '[' -d /run/udev ']'
++ return 0

So, down the rabbit hole...
[email protected]:~# apt-get install udev
...
udev is already the newest version.

So I google and find this post: http://www.raspberrypi.org/forums/viewt ... 8&start=25
hmmm...

[email protected]:/run/udev# cd /lib/udev/rules.d/
[email protected]:/lib/udev/rules.d# vi 85-hwclock.rules
this leads to
/lib/udev/hwclock-set

As this point I edit the file and change the --systz to -hctosys, set the clock and reboot.

A thing of pure beauty happens:
[email protected]:~# date
Tue Feb 10 19:57:03 AEST 2015

So, in summary, past the initial stuff of enabling i2c, ds1307 (devicetree) etc:
1. ignore hwclock.sh, it's a fake!
2. fix /lib/udev/hwclock-set
3. set the clock initially with ntpdate and hwclock -s (although this may happen automatically if you leave things long enough).

Now all I need is a way to tell devicetree to enable my clock as a ds3231 as a parameter to the ds1307 devicetree load. I'm not looking in PhilE's direction AT ALL :)

Time for a beer!

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2444
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: I2C RTC wipe/corruption on new kernel boot?

Tue Feb 10, 2015 11:20 am

Congratulations - a nice piece of detective work.

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Feb 12, 2015 11:22 am

The fun did not stop there once I upgraded to Jessie.

For the further fixes (not hardware related) see http://www.raspberrypi.org/forums/viewt ... 62#p692662

User avatar
PeterO
Posts: 5084
Joined: Sun Jul 22, 2012 4:14 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Wed Mar 04, 2015 8:01 pm

PhilE pointed me at you for fixing my rtc problem and all is good.
I have one question though...
marcus15 wrote: So, in summary, past the initial stuff of enabling i2c, ds1307 (devicetree) etc:
1. ignore hwclock.sh, it's a fake!
2. fix /lib/udev/hwclock-set
3. set the clock initially with ntpdate and hwclock -s (although this may happen automatically if you leave things long enough).
What does "ignore hwclock.shm it's a fake" mean ? I have an PI1 that I set up with an RTC a while ago and as far as I remember it was needed then.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Mar 05, 2015 9:28 am

What does "ignore hwclock.shm it's a fake" mean ? I have an PI1 that I set up with an RTC a while ago and as far as I remember it was needed then.
You are correct for the most part, but there are a few lines at the start of hwclock.sh that check for udev and systemd (*spew*) which take effect once you're running Raspian Jessie. Put a 'set -x' at the start of hwclock.sh and you'll see what I mean! Please post corrections here or in the other thread if I'm wrong; as you can see form my posts it was a very iterative debugging process and I scraped together my notes at the end.

I still haven't had time to put in a request to have the time/rtc setting option re-enabled in the kernel... I've been very busy.

FYI, this explains a lot: http://devopsreactions.tumblr.com/post/ ... emd-evolve

User avatar
PeterO
Posts: 5084
Joined: Sun Jul 22, 2012 4:14 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Mar 05, 2015 9:53 am

marcus15 wrote:
What does "ignore hwclock.shm it's a fake" mean ? I have an PI1 that I set up with an RTC a while ago and as far as I remember it was needed then.
You are correct for the most part, but there are a few lines at the start of hwclock.sh that check for udev and systemd (*spew*) which take effect once you're running Raspian Jessie. Put a 'set -x' at the start of hwclock.sh and you'll see what I mean! Please post corrections here or in the other thread if I'm wrong; as you can see form my posts it was a very iterative debugging process and I scraped together my notes at the end.

I still haven't had time to put in a request to have the time/rtc setting option re-enabled in the kernel... I've been very busy.

FYI, this explains a lot: http://devopsreactions.tumblr.com/post/ ... emd-evolve
Thanks.

Last evening I tried my RTC on PIB+ running latest Raspbian (but not with latest firmware). It already had I2C/DT enabled (for other device) and your changes to udev script and disabling the fake clock were all it needed. I did note that I2C clock DT overlay files have been changed but it was obvious which overlay file to use.

I wonder how long it will take for all the "How to install an I2C RTC" web pages to be updated :lol:

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Mar 05, 2015 10:49 pm

marcus15,

I actually ended up running into similar issues with RTC corruption on the UPS Pico board with the Pi2B yesterday after I installed ntp. Thank you for posting about your experience and the link to the other thread. There seem to be at least a couple decent approaches/solutions presented there. For now I've just removed ntp as I am not interested in fiddling around with getting them to play well with each other.

Thanks again,
KTB

marcus15
Posts: 14
Joined: Sat Feb 07, 2015 11:58 pm

Re: I2C RTC wipe/corruption on new kernel boot?

Fri Mar 06, 2015 3:45 am

I actually ended up running into similar issues with RTC corruption on the UPS Pico board with the Pi2B yesterday after I installed ntp. Thank you for posting about your experience and the link to the other thread. There seem to be at least a couple decent approaches/solutions presented there. For now I've just removed ntp as I am not interested in fiddling around with getting them to play well with each other.
Yep that interaction of the kernel not having set the system clock from hardware, then NTP trying to save the unset clock on start up, corrupting the hardware clock is a really nasty interaction! I really should put that bug report in. When I do I'll post back here and people can vote for it or however that works...

serkanp
Posts: 9
Joined: Thu Jun 04, 2015 11:15 am

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 11:24 am

hi ,
i have 4 rtc ds3231 (supercapacitor and battery version also)

i fix /lib/udev/hwclock-set
i have set /boot/config.txt
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on
device_tree=



i did not used any rc.local setting or not modified the /etc/init.d/hwclock.sh
i have the latest os from official website (raspbian 2015-05-05)
i update, upgrade, dist-upgrade, rpi-update
i updated to the latest kernel :
Linux smgplayer 3.18.14-v7+ #793 SMP PREEMPT Sat May 30 14:04:35 BST 2015 armv7l GNU/Linux

while reboots, the rtc3231 works without any problem.
but when i power off - on , then the rtc resets itself to sat 1 jan 2000

i spend hours and hours, still nothing.. (even i tried pidora, mate ubuntu, updated to jessie etc)
i thought maybe the rtc is broken :) i removed and put another.. still the same

here is the output:

[email protected] ~ $ echo ds3231 0x68 | sudo tee /sys/class/i2c-adapter/i2c-1/new_device
ds3231 0x68
[email protected] ~ $ sudo hwclock -r --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1433416107 seconds after 1969
Last calibration done at 1433416107 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2015/06/04 11:09:26
Hw clock time : 2015/06/04 11:09:26 = 1433416166 seconds since 1969
Thu 04 Jun 2015 14:09:26 EEST -0.209391 seconds
[email protected] ~ $ sudo reboot

[email protected] ~ $ echo ds3231 0x68 | sudo tee /sys/class/i2c-adapter/i2c-1/new_device
ds3231 0x68
[email protected] ~ $ sudo hwclock -r --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1433416107 seconds after 1969
Last calibration done at 1433416107 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2000/01/01 00:02:13
Hw clock time : 2000/01/01 00:02:13 = 946684933 seconds since 1969
Sat 01 Jan 2000 02:02:13 EET -0.468657 seconds


need help :))

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2444
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 12:25 pm

You can make your life easier by enabling device tree (remove or comment out "device_tree=") and adding an overlay for your rtc:

Code: Select all

dtoverlay=i2c-rtc,ds3231
Then follow the rest of the instructions in this post: viewtopic.php?p=730183#p730183

I'm guessing you still have the fake-hwclock installed, or your aren't deleting /etc/adjtime.

serkanp
Posts: 9
Joined: Thu Jun 04, 2015 11:15 am

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 12:35 pm

sorry i did not told about it..
i removed the fake-hwclock and purged it..
also disabled the ntp

i enabled device tree before and after soft reboots , date year becomes 2066 :))
then i disabled it..

serkanp
Posts: 9
Joined: Thu Jun 04, 2015 11:15 am

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 12:42 pm

PhilE wrote:You can make your life easier by enabling device tree (remove or comment out "device_tree=") and adding an overlay for your rtc:

Code: Select all

dtoverlay=i2c-rtc,ds3231
Then follow the rest of the instructions in this post: viewtopic.php?p=730183#p730183

I'm guessing you still have the fake-hwclock installed, or your aren't deleting /etc/adjtime.


after adding dtoverlay and removing device_tree=
and also removing the adjtime..

here is the output:
[email protected] ~ $ sudo rm -rf /etc/adjtime
[email protected] ~ $ sudo hwclock -r
Sat 01 Jan 2000 03:27:39 EET -0.665389 seconds
[email protected] ~ $ date
Sat Jan 1 03:27:41 EET 2000
[email protected] ~ $ sudo ntpd -gq
ntpd: time set +486731374.883228s
[email protected] ~ $ sudo hwclock -w
[email protected] ~ $ sudo hwclock -r
Thu 04 Jun 2015 15:37:38 EEST -0.946943 seconds

power on-off

[email protected] ~ $ sudo hwclock -r
Sat 01 Jan 2000 02:00:54 EET -0.123124 seconds


still the same:

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2444
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 12:44 pm

But you are using Device Tree and typing less, which is good.

serkanp
Posts: 9
Joined: Thu Jun 04, 2015 11:15 am

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 12:45 pm

:)) same sh*t but brown color..

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2444
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 12:51 pm

A few ideas:
1) Are you sure the battery is good?
2) Try unplugging the clock and reconnecting while the system is running.
3) Try unplugging the clock, rebooting and then reconnecting the clock once the system is running again.

serkanp
Posts: 9
Joined: Thu Jun 04, 2015 11:15 am

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 1:07 pm

hi again,

acually i have 140 rpi2 device and 144 rtc :)

now on my desk, i have 2 rpi2 and 2 super capacitor , 2 battery powered ds3231

A few ideas:
1) Are you sure the battery is good?
2) Try unplugging the clock and reconnecting while the system is running.
3) Try unplugging the clock, rebooting and then reconnecting the clock once the system is running again.
1- i am sure they have enough battery..
2- while system is running, unplug and plug makes the same reset to 1/1/2000
3- without rtc, restarted the system, plugged it after login to ssh, system does not see it..
here is the output:

Code: Select all

[email protected] ~ $ sudo hwclock -r
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.
[email protected] ~ $ echo ds3231 0x68 | sudo tee /sys/class/i2c-adapter/i2c-1/new_device
ds3231 0x68
tee: /sys/class/i2c-adapter/i2c-1/new_device: Invalid argument
[email protected] ~ $ sudo hwclock -r
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.
this is very urgent for us, we have a music player system runs on rpi2, and in some customers, they dont have internet connection near the device.. so player have its own db , depending on rtc, it plays the schedules and ads..

so for the last 3 days.. i am stucked..

now i am preparing a ardunio test and i will see if it is related to rtc or not..

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2444
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: I2C RTC wipe/corruption on new kernel boot?

Thu Jun 04, 2015 1:15 pm

Your answer to 2) makes me think the clock just isn't holding its time, rather than it being corrupted by the reboot (which is what used to happen before the hwclock-set fix). But I'm not an RTC expert, and I've run out of ideas. Trying on an Arduino should help to narrow down the problem.

Return to “Interfacing (DSI, CSI, I2C, etc.)”