Orange Pi Zero: internal RTC

[Arjan van Vught]

Dear forum,

 

When looking at the Orange Pi Zero schematic V1.1, the OSC-RTC box is empty. Does this mean that there is no crystal for the internal RTC? The internal RTC cannot be used at all?

 

When just checking the time register, the RTC is running too fast.

 

Thanks, Arjan

[martinayotte]

38 minutes ago, Arjan van Vught said:

The internal RTC cannot be used at all?

RTC is by default set to run with internal OSC, so no need for external one.

39 minutes ago, Arjan van Vught said:

When just checking the time register, the RTC is running too fast.

How did you check that ?

"hwclock" seem to provide the right time ...

 

[Arjan van Vught]

4 minutes ago, martinayotte said:

RTC is by default set to run with internal OSC, so no need for external one.

The internal clock (which is about 16MHz) does not give an accurate reference. So I did not try to use that option.

I will check your source code for the configuration.

 

6 minutes ago, martinayotte said:

How did you check that ?

Just reading the register directly and printing the value when the seconds have changed.

[Arjan van Vught]

12 minutes ago, martinayotte said:

RTC is by default set to run with internal OSC, so no need for external one.

This https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L499 is referencing to an external OSC.

[martinayotte]

14 minutes ago, Arjan van Vught said:

This https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L499 is referencing to an external OSC.

Right ! But since the RTC has no external source, it stays with internal one.

Check the registers description of Allwinner H3 user manual and check values with "devmem2"

"devmem2 0x01f00000" report 0x0001, which is effectively mean LOSC_SRC_SEL bit is set to External, but "devmem2 0x01f00004" (the LOSC_AUTO_SWT_STA_REG) report 0x4, where LOSC_SRC_SEL_STA status bit is 0 meaning InternalOSC.

To my understanding, the LOSC_AUTO_SWT_STA_REG autoswitch probably detect that there is no clock present and doesn't switch the clock ...

 

Did you verify with "hwclock" on your board if it is accurate ?

[Arjan van Vught]

8 minutes ago, martinayotte said:

but "devmem2 0x01f00004" (the LOSC_AUTO_SWT_STA_REG) report 0x4, where LOSC_SRC_SEL_STA status bit is 0 meaning InternalOSC.

So the check here https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L512 is basically wrong. The CTRL tells what has been set, and then AUTO_STA really tells the status.

 

And the RTC goes into default internal with prescaler 0xF -> 16 MHz / 32 / 15 that is about 33KHz. Which is slightly faster than the desired 32768 Hz. 

[martinayotte]

18 minutes ago, Arjan van Vught said:

So the check here https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L512 is basically wrong. The CTRL tells what has been set, and then AUTO_STA really tells the status.

You're right ! I don't see those warning in my dmesg ... something fishy there ... But, at least, it still seems to work in my case.

 

EDIT: Oh ! But rtc-sunxi.c doesn't even look at LOSC_AUTO_SWT_STA_REG, it is only validate that write to SUNXI_LOSC_CTRL_REG was successful ... hmmm !

[Arjan van Vught]

Simple test

pi@orangepizero:~$ cat ./rtc_test.sh
while true
do
        ./dev2mem 0x01f00014 | tail -n 1
        echo `date +"%S"`
        sleep 1
done

 

pi@orangepizero:~$ sudo ./rtc_test.sh

Value at address 0x1F00014 (0xb6ff7014): 0xF162D

22

Value at address 0x1F00014 (0xb6f63014): 0xF162E

23

Value at address 0x1F00014 (0xb6f09014): 0xF162F

24

Value at address 0x1F00014 (0xb6f4a014): 0xF1630

25

Value at address 0x1F00014 (0xb6f9f014): 0xF1632

26

Value at address 0x1F00014 (0xb6f0a014): 0xF1633

27

Value at address 0x1F00014 (0xb6ffb014): 0xF1634

28

Value at address 0x1F00014 (0xb6f8b014): 0xF1635

29

^C

 

Skipping a second here. 

 

Quote

pi@orangepizero:~$ cat /etc/armbian-release

# PLEASE DO NOT EDIT THIS FILE

BOARD=orangepizero

BOARD_NAME="Orange Pi Zero"

BOARDFAMILY=sun8i

BUILD_REPOSITORY_URL=https://github.com/armbian/rkbin

BUILD_REPOSITORY_COMMIT=3e533c9

DISTRIBUTION_CODENAME=buster

DISTRIBUTION_STATUS=supported

VERSION=20.02.1

LINUXFAMILY=sunxi

BRANCH=current

ARCH=arm

IMAGE_TYPE=stable

BOARD_TYPE=conf

INITRD_ARCH=arm

KERNEL_IMAGE_TYPE=Image

 

[martinayotte]

10 minutes ago, Arjan van Vught said:

Skipping a second here.

That is not really a good way to test, since your loop is a bit more than 1 second due to execution of previous lines.

Do a sleep of 120 seconds or even bigger, such 1 hour, and calculate the number of seconds elapse between the two devmem2.

[Arjan van Vught]

4 minutes ago, martinayotte said:

hat is not really a good way to test, since your loop is a bit more than 1 second due to execution of previous lines.

Therefore I am also showing the seconds from the date command. I will do another test. However, the apt update/upgrade I just did, it broke the startup. 

[martinayotte]

2 hours ago, Arjan van Vught said:

So the check here https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L512 is basically wrong.

In fact, this URL is completely obsolete, it is a snapshot of code from 4 years ago ...

The current Mainline is here : https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c

But they still don't check the LOSC_AUTO_SWT_STA_REG register ...

 

EDIT: I've done few tests with measurement at 8 minutes intervals, it is loosing/gaining around 8 seconds / 8 minutes, but since it is both loosing/gaining, overall the average should be good.

[Arjan van Vught]

See the remarkable output below. Many observations and some questions:

• The internal RTC seems to be useless with the internal OSC.
• The internal RTC gets updated; once every ? seconds. From which source?
• What is the source for the date command? Specific which ARM Counter or with SoC Timer?
• This test is with an Internet connection; hence the system clock gets updated with the NTP Client. Interesting to know what happens with no Internet connection.

Quote

pi@orangepizero:~$ sudo ./rtc_test.sh

17:00:39

17:00:21

==============

17:02:47

17:02:21

==============

17:04:55

17:04:21

==============

17:07:04

17:06:21

==============

17:08:25

17:08:21

==============

17:10:34

17:10:21

==============

17:12:42

17:12:21

==============

17:14:51

17:14:21

==============

 

pi@orangepizero:~$ cat ./rtc_test.sh 
while true
do
        ./devmem2 0x01f00014 | tail -n 1 |rev|cut -f1 -d' '|rev | ./convert
        echo `date +"%H:%M:%S"`
        echo ==============
        sleep 120
done

/*
 * convert.c
 */

#include <stdio.h>
#include <stdlib.h>

#define TIME_GET_SEC_VALUE(x)			((x) & 0x0000003f)
#define TIME_GET_MIN_VALUE(x)			(((x) & 0x00003f00) >> 8 )
#define TIME_GET_HOUR_VALUE(x)			(((x) & 0x001f0000) >> 16)

int main(void) {
	unsigned num;
	fscanf(stdin, "%x", &num);
	printf("%.2d:%.2d:%.2d\n", TIME_GET_HOUR_VALUE(num), TIME_GET_MIN_VALUE(num), TIME_GET_SEC_VALUE(num));
	return EXIT_SUCCESS;
}

 

[martinayotte]

43 minutes ago, Arjan van Vught said:

See the remarkable output below

That strange, you drifts is really bigger than mines, mines are 1 or 2 or 3 seconds per 2 minutes ...
I've added "hwclock -w" before the loop and get the following results (not that I forgot to add UTC to "date") :

 

 

 

17:30:39
12:30:39
---------------
17:32:41
12:32:39
---------------
17:34:40
12:34:39
---------------
17:36:43
12:36:39
---------------
17:38:46
12:38:39
---------------
17:40:48
12:40:39
---------------
17:42:51
12:42:39
---------------
17:44:54
12:44:39
---------------
17:46:42 <---- drift correction
12:46:39
---------------
17:48:44
12:48:39
---------------
17:50:47
12:50:39
---------------
17:52:50
12:52:39
---------------
17:54:53
12:54:39
---------------
17:56:55
12:56:39
---------------
17:58:43 <---- drift correction
12:58:39
---------------
 

 

 

Yes, it seems that a background process is doing "hwclock -w" in background, maybe every 12 minutes, as you said, most probably the ntp or chrony service ...

BTW, I've the same test on my OPi3 which actually has an external crystal, no drifts at all ...

 

[martinayotte]

1 hour ago, Arjan van Vught said:

Many observations

Some new ones : I've done tests on my OPiPC2, OPiZeroPlus2, OPi+2E, OPiOne and OPiLite which also don't have a external 32768 crystal, drifts are seen only on H3 but not on H5 ...

Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.

[Arjan van Vught]

15 minutes ago, martinayotte said:

.. drifts are seen only on H3 but not on H5 ...

Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.

That's a shame as I am using the Orange Pi Zero LTS 256MB and the Orange Pi One boards only. I will try to contact Steven and ask if it is doable getting the external 32768 crystal on the(se) H2+/H3 boards.

[gounthar]

What would we need besides a crystal to get a RTC hat to work with the Orange Pi Zero?
Thanks.

[Arjan van Vught]

24 minutes ago, gounthar said:

What would we need besides a crystal to get a RTC hat to work with the Orange Pi Zero?
Thanks.

When there is a crystal placed on the OPi board itself,  then there is no need for a hat.

Of course, we also need a proper battery connector -> removing the WiFi chip for making some space.

[gounthar]

But if I was to design a very simple hat, what would be needed ? 

Thanks. 

[Arjan van Vught]

1 hour ago, gounthar said:

But if I was to design a very simple hat, what would be needed ? 

Thanks. 

This topic is about the missing RTC crystal on the OPi board. And therefore we cannot use the RTC in the SoC.

 

When you would like to build an expansion board then for examples; check the dataset for: DS3231 or Google for: rtc i2c board 

[martinayotte]

The PCF8523 chip is a good one since it can trigger an alarm interrupt ...

[Arjan van Vught]

55 minutes ago, martinayotte said:

The PCF8523 chip is a good one since it can trigger an alarm interrupt ...

https://www.adafruit.com/product/3295 -> The PCF8523 is simple and inexpensive but not a high precision device. It may lose or gain up to 2 seconds a day.