-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
saml21 system time vs rtc #10523
Comments
I have seen some bad results with the tests/bench_timer application on samr21-xpro as well. I think the sam0 periph/timer driver is the problem and that it loses ticks, but I have not had time to investigate further. |
Thanks for reporting it back @fedepell ! |
@gebart : I wanted to run the test but am stuck with it, it starts but (as far as I see) then it blocks. As the saml21-xpro has a single timer I put my board under SINGLE_TIMER_BOARDS in the makefile and build and flashed, but then it will start and:
Any hint maybe how I could run it? Thanks a lot! |
@fedepell might be xtimer or something interfering with the hardware timer. Try adding DISABLE_MODULE=xtimer on the command line when building. |
@gebart : thanks for the hint. Sadly didn't change much. I checked a bit more in detail and noticed that it is always stuck at the
At the end of run_test. Seems like mtx_cb is already locked and nothing happens to unlock it. Trying to figure out why now. |
@fedepell I just tested your code on arduino-zero like board. It works like a charm without any drift (after 20 minutes). |
Full result with arduino-zero like:
|
I was trying to work a bit more on this issue, mainly first of all trying to make the bench_timers work on my saml21-xpro and have some more information hoping it may be of some help. First of all as mentioned before (just to make sure I'm not doing something stupid) I put in the Makefile saml21-xpro in SINGLE_TIMER_BOARDS so it uses the only timer. Then what I noticed trying to debug is this: Mainly the test will set a first timer (an absolute one) and then get stuck there on the "mutex_lock(&mtx_cb)". It seems as the ISR callback is actually never called (so mutex never unlocked). First interesting thing I noticed is that while timer_init() is called, it usually does mostly nothing as it will return immediately on the:
So it sees the timer already enabled (on boot outside of timer.c? From pre-boot?) and it will immediately return, without setting further registers and the callback. Commenting out this "return 0" will make things already much better, in the sense that now timer gets alive. Still the test would usually sooner or later stop at some point (always same mutex / ISR never called). Here adding debug prints made the issue mostly disappear so it looked like a timing issue. Interesting enough if the timer is always stopped for the test (so I do a Suggestion: shouldn't the TEST_MIN_REL definition follow the one of TEST_MIN ? (where a differentiation between 1 and 16 is done depending on timer frequency?) I put the output results of the test after the modifications I mentioned here. Not sure how this findings may help in understanding the original problem, but probably having at least the timer benchmark working may be something to begin with. Maybe @kaspar030 or @thomaseichinger can have some comments and ideas? |
Test output of a run on saml21-xpro:
|
One more output from a longer run, but I think statistically is quite similar:
|
@fedepell The time() function is wrongly implemented in that it returns time since boot, using xtimer (instead of the RTC). I have a PR open since a while ago (#9258 ). I think this commit in particular might solve your issue. I might have screwed up by changing the implementation and splitting the modules in the same PR. If the time()/RTC thing is an issue, I might split the change. |
@jcarrano: thanks for the pointer, I'll try to check out the PR/commit! Mostly I was finding it strange that the system time is so "quite wrong" (15 sec in 1 hour), so I was more concerned about the fact that if I (conceptually) do a xtimer_sleep of 1 hour I will be woken up with 15 full seconds of error (which is not little on 1hour, I believe). |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Description
System time on my saml21-xpro seems to be quite innacurate, both compared to the RTC and to an external source. In about 1 hour I can see a drift of about 15 seconds which seems quite a lot.
Is this to be expected or could something be lying behind that could be analyzed better? (I can try to give a deeper look if this is not expected)
Steps to reproduce the issue
I did a simple application that has a loop that every minute reads the system time, reads the RTC time and prints them out. Something more or less like:
RTC is initialized at some known value at the beginning.
Expected results
I would expect them to run roughly at the same speed.
Actual results
I see a drift of about 15 seconds in an hour which sounds quite something to me. Compared to an external source (my PC) the time read from the RTC is the correct one, as that one is aligned (at least after a couple of hours and to a precision of 1 sec) to the PC.
What I see running the test is (I omit some iterations) for example:
So the system time seem to be running slower than the RTC/real one. While I could understand some degree of imprecision I would think that 15 seconds per hour sounds quite high. While the RTC (that could be tuned eventually) seems to perform quite ok.
Is this behaviour expected ?
I saw this behaviour on a custom hardware but then to clear doubts about the hardware implementation I tried also on the EVB and got the same results indeed. Also on custom hardware the RTC seemed to run fine, while the system time was drifting, but interestingly enough not always at the same speed, always lagging but not always at the same speed.
The text was updated successfully, but these errors were encountered: