A20: internal RTC gets stuck

[-peter-]

Hello folks,


we have a problem with our A20 on-chip RTC:

the RTC source clock is set to the external 32768 crystal, the oscillator is running (checked with oscilloscope), the RTC_VDD is at 1.3V. The board is powered by AXP209 with a backup battery.
Everything seems fine, just like on the unaffected board, but the RTC just does not count.

Checking the LOSC_CTRL_ REG register with "busybox devmem 0x01c20d00" yields: 0x00000189, which means that the write to the date and time registers is not yet complete.
No matter how many write attempts I make, nothing helps.

The only way to get it working again is to remove the battery from the AXP209 and disconnect the power supply for a few seconds.

I wonder if there is a software solution to get the RTC working again after it gets stuck?
Is there any command to hard-reset the internal RTC?

With best regards,
Peter

[LubOlimex]

You are probably reading the wrong RTC...

[-peter-]

this is the only one 
The point is, we have plenty of boards out there and some of them get stuck, some do not.

[LubOlimex]

What happens if you run hwclock instead of registry read? Do the following test:

- set and run hwclock
- disconnect main power supply, wait 10 minutes
- start the board run hwclock again and check if 10 minutes had passed

If the issue occurs only with some boards, then probably the RTC quartz is damaged somehow and needs replacing.

[LubOlimex]

You can set the hwclock with hwclock --systohc

[-peter-]

Hi,

"hwclock -r" doesn't even work:

hwclock: select() to /dev/rtc0 to wait for clock tick timed out

that's why i was talking directly about register, just bypassed all this linux driver stuff and talked straight to the A20 RTC hardware.

Looking at the hardware interface of the A20 RTC (see: A20 Manual, start at Chapter 1.9.3.26) we find a set of registers, these are used by the linux RTC driver (see: RTC SUNXI Driver) giving a unified software interface we know as /dev/rtc0 to the user. Which is being used by hwclock shell command.

Well, back to the registers, here comes an example of a working case:

address:    content
----------------------
0x01c20d00: 0x00000009
0x01c20d04: 0x0035060F   <--- Date
0x01c20d08: 0x000A2D0F   <--- Time: this is being increased once per second (try: "busybox devmem 0x01c20d08")
0x01c20d0c: 0x00000000
0x01c20d10: 0x00000000
0x01c20d14: 0x00000000
0x01c20d18: 0x00000000
0x01c20d1c: 0x00000000

and here from a stucked one:

0x01c20d00: 0x00000189   <--- here seems to be the problem
0x01c20d04: 0x0035060F   <--- Date
0x01c20d08: 0x000A2712   <--- Time: it doesn't change
0x01c20d0c: 0x00000001
0x01c20d10: 0x00000000
0x01c20d14: 0x00000000
0x01c20d18: 0x00000000
0x01c20d1c: 0x00000000

I can issue a "hwclock -w" or "hwclock --systohc" which in fact does not even complain, but this doesn't mean the RTC is working. The RTC_YY_MM_DD_REG and RTC_HH_MM_SS_REG have been written, but the RTC itself doesn't run.

The problem is that the bits RTC_YYMMDD_ACCE and RTC_HHMMSS_ACCE were not reset after a write operation. Why this happens is not clear to me.

Simple reboot or even reset the board doesn't help. To get out of this state, i need to remove power supply and battery.

Crystal seems to be ok, because even if the RTC is not running, the crystal is oscillating properly, i've compared the signals with a unaffected board: same amplitude, same frequency. Even if i switch the RTC clock source to the internal oscillator (which doesn't need the crystal at all) it doesn't change anything.
The point is: the "affected" boards are only temperaily affected, after removing power supply and battery they are working properly, until the fail again, when? I don't know.

I'm currently struggling with how this might happen, because i did not manage to reproduce this "stuck"-state. This happens seemingly after a while in random manner and i'm looking a software solution as a workaround.

with best Regards
Peter

[LubOlimex]

I believe each a20 board has at least two RTC, one external and one internal. I've seen people set or read internal one by mistake saying external RTC is slow or fast.

What image are you using? hwlock works properly here, maybe for the sake of testing boards in question try unmodified Olimage image, this is what I see:

Code Select Expand

root@a20-olinuxino:~# hwclock
2023-06-15 14:41:07.251263+00:00
root@a20-olinuxino:~# hwclock --systohc
root@a20-olinuxino:~# hwclock
2023-06-15 14:41:23.483404+00:00
root@a20-olinuxino:~# hwclock -r
2023-06-15 14:41:41.598727+00:00
root@a20-olinuxino:~#

[LubOlimex]

Wondering what would happen if you also attach compatible battery to AXP_BACKUP, which board do you have, some older revisions might not have it exposed.

[-peter-]

The A20-OLINUXINO-Micro seems to not having a second one.
We have a custom board based on OLINUXINO-A20-Micro. We are using batteries bought directly from OLIMEX, so i guess is a compatible one.

This issue seems to be a A20 chip related, not board related.

With best Regards,
Peter

[LubOlimex]

You were using 3.7V Li-Po batteries or I got that wrong? I meant 3V batteries for only RTC backup.

[-peter-]

yes, 3.7V 1400mAh