Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9985 - AMS Sansa RTC fixes

Attached to Project: Rockbox
Opened by Bertrik Sikken (bertrik) - Thursday, 05 March 2009, 19:59 GMT+2
Last edited by Bertrik Sikken (bertrik) - Saturday, 09 May 2009, 22:04 GMT+2
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Player Type Sansa e200
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

It seems the newer ams sansas keep time in the rtc as seconds since 1-1-1970, while older sansas keep time in the rtc as seconds since 1-1-1980. Currently rockbox uses the exact same piece of code for both types. This can result in a problem with the following symptoms on ams sansas:
* after setting the current date in rockbox and booting the OF, the date is reset to some other value.
* rockbox shows a date that is approximately 10 years (+/- 1 day) later than the date shown in the OF.

It is not entirely clear if all ams sansas suffer from this problem, but at least the e200v2 seems to do so, also the fuze was reported as having problems with the date/time. This patch uses a different reference date of 1-1-1970 for the c200v2, e200v2 and the fuze. All other players use the old reference date of 1-1-1980.

Please report if this patch stops the symptoms described above.
   rtc_ams_sansa.patch (1.8 KiB) 
 firmware/drivers/rtc/rtc_as3514.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

This task depends upon

Closed by  Bertrik Sikken (bertrik)
Saturday, 09 May 2009, 22:04 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  Committed in svn r20697
Comment by Hilton Shumway (HIllshum) - Friday, 06 March 2009, 03:26 GMT+2
I get neither of those symptoms. However, the calendar plugin gives a calendar but the months don't start when they should(March 09 is shown starting on a Friday, March 04 starts on Sunday) while writing the current date to the screen. This seems to be a lack of telling that plugin that the RTC is set ten years earlier.
Comment by Bertrik Sikken (bertrik) - Friday, 06 March 2009, 08:57 GMT+2
I think the calendar plugin does not need to know how the rtc stores its time internally. This could also be a bug in the calendar plugin. I can't reproduce this on my sansa clip.
What player do you have? Is the System/Time & Date screen showing the correct date and time?
Comment by Bertrik Sikken (bertrik) - Friday, 06 March 2009, 09:42 GMT+2
Oh it looks you're right, the RTC driver is responsible too for calculating the day of week and the current formula is tailored for a reference date of 1980 and fails for a reference date of 1970. This bug isn't actually all that noticeable except in the calendar plugin, so good catch!

Another way of fixing the problem is to stick to the current convention of using 1980 as reference year and adding/subtracting 315532800 just before writing/reading the raw seconds value. 315532800 is the exact number of seconds difference between 1970-1-1 and 1980-1-1.
Comment by Jack Halpin (FlynDice) - Friday, 06 March 2009, 19:49 GMT+2
This patch is working strangely on my e280v2. I had some strange time changes when flipping back and forth between rockbox and OF that seemed to dissappear after 2-3 changes. Time is stable now when switching. The other thing is that when I set the time now in rockbox settings I it makes the date 2 days earlier. ie setting March 6 in the settings window and saving gives me a date of March 4. If I set March 8 in the settings page it ends up at March 6. Neither rockbox nor the OF seem to mind though.
Comment by Jack Halpin (FlynDice) - Friday, 06 March 2009, 19:54 GMT+2
One more thing I meant to mention. After trying this patch out the first time I got into a loop somewhere that bricked the player until I took the battery out. Don't know if that's just coincidence as I was not fiddling with the time settings at that point. I thought my player was shut off and 10 mins later my pocket started getting warm.....
Comment by Hilton Shumway (HIllshum) - Friday, 06 March 2009, 20:09 GMT+2
"it makes the date 2 days earlier"

I was getting that for a while on my e260v2 but it seems to be fine now
Comment by Hilton Shumway (HIllshum) - Friday, 06 March 2009, 20:47 GMT+2
Never mind, it's there. This may be a problem with calculating the weekday on the set time screen. The OF seems to show the same 2 days after RB does after setting it, while dealing with dates like march 6 (today). march >10 it really weird
Comment by Bertrik Sikken (bertrik) - Friday, 06 March 2009, 21:13 GMT+2
Here's a simpler patch. It simply adjust the seconds just after reading and just before writing the RTC second register.
   rtc_ams_sansa2.patch (1.3 KiB) 
 firmware/drivers/rtc/rtc_as3514.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comment by Jack Halpin (FlynDice) - Saturday, 07 March 2009, 19:36 GMT+2
Setting the time in rockbox seems to work fine. The of will sometimes pick up the change or sometimes not, I couldn't recognize a pattern of success or failure. Setting the time in the of does not seem to transfer back to rockbox. The main thing I noticed though was every time I came back to rockbox the time was correct. Even after updating the rockbox firmware.
Comment by Michael Chicoine (mc2739) - Sunday, 08 March 2009, 00:02 GMT+2
On my E260, the seconds offset does not appear to be correct. When you set the date in Rockbox, the same date does is not displayed in the OF. The same is true when the date is set in the OF. It seems to be off by approximately 16 months. By changing the offset to 357004800 (increased by 480 days), the date is the same when switching between Rockbox and OF.
   rtc_ams_sansa3.patch (1.3 KiB) 
 firmware/drivers/rtc/rtc_as3514.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comment by Michael Chicoine (mc2739) - Sunday, 08 March 2009, 00:07 GMT+2
Disregard my previous ramblings. There is still an issue even with patch rev 3.
Comment by Dustin Skoracki (sko) - Saturday, 11 April 2009, 10:11 GMT+2
I'm using this patch for a while now and it is working really good, the only issue i could found is that the time (just time, not date) is incorrect after a firmware-update.
Comment by Bertrik Sikken (bertrik) - Saturday, 11 April 2009, 10:57 GMT+2
If a simple offset between OF time and Rockbox time doesn't work, then this should be investigated more systematically.
For example, we could temporarily disable setting date/time in rockbox and just expose the raw time value through a debug menu. Then try out setting various dates/times in the OF and see how they map to the raw value in rockbox.
Comment by Hilton Shumway (HIllshum) - Saturday, 11 April 2009, 16:14 GMT+2
If the latest one doesn't cause the OF to mess with the time, could it be committed as a temporary fix?
Comment by Michael Chicoine (mc2739) - Sunday, 12 April 2009, 02:09 GMT+2
Here is the latest version of this patch that I have been using. I am not seeing any offset in the date or time.
   rtc_ams_sansa4.patch (1.3 KiB) 
 firmware/drivers/rtc/rtc_as3514.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comment by Bertrik Sikken (bertrik) - Sunday, 12 April 2009, 08:37 GMT+2
Patch rtc_ams_sansa4.patch is identical to patch rtc_ams_sansa2.patch, in which the seconds adjustment is exactly equal to the time difference between 1970-1-1 and 1980-1-1 unix time. Was this your intention?
Comment by Michael Chicoine (mc2739) - Sunday, 12 April 2009, 15:43 GMT+2
I did not realize that I had that I had changed back to the same adjustment as rtc_ams_sansa2.patch.

I did notice that if the time is adjusted in the OF, the change is not changed in Rockbox. But if the time is changed in Rockbox, it is also changed in the OF.
Comment by Bertrik Sikken (bertrik) - Sunday, 12 April 2009, 20:04 GMT+2
The adjustment of the date/time (equal to seconds between 1970-1-1 and 1980-1-1) for all AMS sansas was committed as svn r20697. Let's keep this task open a little longer for success/failure reports.
Comment by Doru Barbu (fragilematter) - Sunday, 12 April 2009, 21:23 GMT+2
I just tested it on my e250v2, svn 20697. I've set the time correctly in rockbox. When switching to OF, the time was two hour early (20:01 instead of 22:01) and the date was set to 31 Oct. 2010. Then I resetted it in the OF and rebooted to rockbox, where it is displayed properly. I switched the clock to 10:10 in rockbox, rebooted to of, it was 10:10. Then I changed it back to 22:08 in of, rebooted to rockbox, it was still 10:10. I left it that way and changed to OF, where it was 22:08 now. Changed back to rockbox, 10:16 (the time it took me to write this and fiddle with the of) again. Corrected in rockbox (22:16), 10:12 in OF and the date 13th April. Changed it back to the correct date and time, rebooted to rockbox - they seem to be in sync now.
I can't see a pattern in this...
Comment by Rafaël Carré (funman) - Thursday, 23 April 2009, 14:30 GMT+2
wasn't this patch committed?
Comment by Hilton Shumway (HIllshum) - Thursday, 23 April 2009, 16:16 GMT+2
Yes, but there's still some buggyness. The reason for commit was to keep the OF from messing with the time.
Comment by Eric Shattow (lucent) - Saturday, 09 May 2009, 12:29 GMT+2
Findings for Fuze 8gb and RB svn r20883:
Set date "May 09 2009 04:18" from OF; Read date "Aug 09 2009 04:19" from RB.
Set date "May 09 2009 04:18" from RB; Read date "Feb 06 2009 04:17" from OF.
Comment by Bertrik Sikken (bertrik) - Saturday, 09 May 2009, 22:04 GMT+2
The weird behaviour of the OF time not getting transferred to Rockbox can be explained as follows:
The OF probably doesn't touch the RTC at all when setting the time (except when it detects a completely invalid date/time). Instead it just adjusts an internal offset between RTC time and actual time. This explains why OF time never transfers back to Rockbox, but it does the other way. This mechanism is probably meant for DRM purposes, so setting the date/time in rockbox may mess up your DRM'd tracks in the OF. The date/time set in Rockbox should now be quite close to the intended OF date/time anyway.

Since there's a explanation now, I'm closing the task.

Loading...