timestamps on SD card wrong

[udo-munk]

I got my first Pico 2 boards the other day and found that the datetime RTC is not available anymore. So I modified the application to use the AON timer and that works ok. But with this the date of created/modified files on SD card is wrong. When I set todays date 10.09.2024 files on the SD card show 10.08.2044, so totally off. The time is correct though.

[carlk3]

Try the dev branch. I made some changes the the RTC stuff yesterday. I'm unable to test it though, since I haven't received a pico2 yet.

How are you checking the date of created/modified files? I've noticed that Windows and Linux deal with those timestamps differently. Linux seems to assume that the timestamps are in GMT (or UTC) time and applies a timezone conversion to local time. Windows, I think, assumes they are in local time already.

[udo-munk]

On Windows and OSX the timestamp show the same, excately like my wall clock, which I use to set the time in the Pico. Not dealing with the timezones yet in the Pico, also don't know if it even is implemented in all the time/date conversion functions.

OK, will try out the dev branch tomorrow and let you know if it changes something.

[udo-munk]

Tried with the dev branch, but the date of the filestamps still is 20 years - 1 month in the future.

[udo-munk]

The one month low probably is because tm_mon contains 0-11 for the month and not 1-12. No idea where the 20 years difference come from, I set tm_year to current year - 1900, convert struct tm with mktime() and start the AON timer with this. On the RP2040 boards I am still using lib version v2.3.2 with the datetime RTC. Timestamps with this are OK.

[sghctoma]

Hi, Just a small addition: I'm using v3.3.0 on the original Pico (RP2040), and the same thing is happening here.

[udo-munk]

Yep, something definitely wrong with the rtc.c/my_rtc.c source. I just modfied my_rtc.c from the dev branch so:

// bit31:25
// Year origin from the 1980 (0..127, e.g. 37 for 2017)
//uint8_t yr = t.tm_year - 1980;
uint8_t yr = t.tm_year - 1900;
fattime |= (0b01111111 & yr) << 25;
// bit24:21
// Month (1..12)
//uint8_t mo = t.tm_mon;
uint8_t mo = t.tm_mon + 1;

Now the month is correct because tm_mon is not 1-12, but year is 1996, hum, 28 years to low now.

[udo-munk]

Now it is working correct with:

// bit31:25
// Year origin from the 1980 (0..127, e.g. 37 for 2017)
//uint8_t yr = t.tm_year - 1980;
uint8_t yr = t.tm_year + 1900 - 1980;
fattime |= (0b01111111 & yr) << 25;
// bit24:21
// Month (1..12)
//uint8_t mo = t.tm_mon;
uint8_t mo = t.tm_mon + 1;
fattime |= (0b00001111 & mo) << 21;

[sghctoma]

Yep, I just started typing that -80 would be the correct number, and you were running into and integer underflow situation with the -1900/-1980.

[carlk3]

OK, thanks for the corrections. I have pushed an update to the dev branch.

[udo-munk]

You are welcome. Got latest update of the dev branch and can confirm that it is working OK on rp2350.