RTC Clock calibration question

[JimTal001]

I found that my pyboard RTC clock is running 70 second slower than my PC clock (adjusted by network) over a 1 hour test period.
That is 70/3600 -> 1.9% -> 19000 ppm. As per the documents it is only adjustable from -488 to +488 ticks.

What is the adjustment method in this case?

Note: my cpu is running at 120 mHz

[blmorris]

That is much too far off for a properly functioning RTC crystal; if correct, it seems like something is broken.
There have been some other reports of RTC measurements on different pyboards, all of the measured offsets were reported to be less than 200ppm, or a few seconds per day (which is still a lot for this kind of crystal.)

-Bryan

[JimTal001]

I verified my results again with an over night test. Over a total test time of 57849 sec (16 hr) the RTC lost 1079 second.
1079/57849 -> 1.86% -> 18,600 ppm

In boot.py I have: pyb.freq(120000000)
I am using the following code which uses standby() and a 10 sec sleep between wake and print the current time.

Code: Select all

import pyb, stm
import micropython

rtc = pyb.RTC()
sleepTime = 10000 # in ms

def main():
	if (stm.mem32[stm.RTC + stm.RTC_BKP1R] == 0): # first boot, Code to run on 1st boot only
		rtc.datetime((2015,10,19,1,16,45,0,0))
		print(rtc.datetime())
		
	print(rtc.datetime())
	rtc.wakeup(sleepTime)
	stm.mem32[stm.RTC + stm.RTC_BKP1R] = 1 # indicate that we are going into standby mode
	pyb.standby()
	
main()

[blmorris]

I assume that you have your REPL on one of the UARTs rather than on USB? The 'standby()' command will kill any USB connection, of course.

Asking because I would like to replicate your setup to see what I get. I know that the RTC on my board runs closer to real time, and going into standby mode shouldn't affect the RTC, but I would like to check.

-Bryan

[JimTal001]

Hello Bryan,

In boot.py I have:

Code: Select all

import pyb
import micropython
pyb.usb_mode(None)
uart = pyb.UART(4,115200)
pyb.repl_uart(uart)
pyb.main('time_cal.py')

I am running a test now with the CPU running at 168 MHz and after 1 hr it appears that the RTC is off by over one minute.
My next test is to not use suspend() mode. I will report findings.

[JimTal001]

Bryan,

I removed suspend() from the code, as follows:

Code: Select all

import pyb, stm
import micropython
rtc = pyb.RTC()
def main():
	while True:
		print(rtc.datetime())
		pyb.delay(10000)

rtc.datetime((2015,10,20,2,10,35,0,0))	
main()

and after 1-1/2 hour, the RTC offset from the PC clock is virtually nil. Therefore, there must be a bug related to suspend() mode and the RTC clock.

Note: my RTC clock is not currently powered by VBAT

next test: Power VBAT and use suspend() mode.
Results of Test: VBAT power does not fix issue.

[blmorris]

JimTal001 - That is good news, in a way; at least the RTC hardware on your board isn't broken or defective.

I come to the same conclusion as you, software bug in the interaction between pyb.standby() and pyb.rtc()

The thing to do now is to open an issue on GitHub with a simple code example to replicate the issue (what you have pretty much done here.) I could open the issue for you if you don't want to do it yourself, but you ought to get credit for finding it

Unfortunately I haven't had a chance to run your tests myself and won't get to dig in to it today, but this is certainly solid enough to report.

-Bryan

[JimTal001]

I will do so but don't know the official path to open the issue. I'll dig around for it.

[dhylands]

Goto https://github.com/micropython/micropython and then click on "Issues" over on the right hand side (<> Code should be selected by default).

Once there, you should find a green "New Issue" button. To paste in code, use triple backticks, something like:

Code: Select all

```python
print('Your python code here')
```

The word python after the triple backticks tells it what language the block is (you can also just use triple backticks with no language specified). If there is a language specified it will try to colorize it using language specific knowlegde.

[JimTal001]

Thanks Dave,

Currently I'm testing pyb.stop() to see if it behaves like pyb.standby(), after this final test I'll report the issue.
Addon: The mode pyb.stop() does NOT have this issue. Issue uploaded to GitHub (#1523)