T4 rtc setting with time change

Status
Not open for further replies.

wwatson

Well-known member
Has anybody noticed that the RTC hour setting did not change with the time change? I just noticed it after uploading a sketch to the T4. I popped the RTC battery out and powered off the T4. The time changed to JAN 1, 1970 as expected. Uploaded the sketch again and the RTC was still off by one hour.
The time on my desktop computer is correct.
Am I missing something?

EDIT:

I just used the processing sketch to set the RTC time. It set the RTC to the correct time. Uploaded a sketch and the RTC was off by one hour again.
 
Last edited:
I'm seeing the same thing. It appears that the loader thinks we're still in DST.

I'm curious; after you use your processing sketch to set the RTC time, does the change survive when you remove the USB cable to the Teensy and then replace it? I'm betting that you see the time jump ahead an hour again. The set() routine in cores/teensy4/rtc.c only sets the RTC, not the SRTC (which is the bit that runs off the RTC battery and actually keeps time when you pull the USB cable). I've modified the set() routine to actually set the SRTC and then sync the RTC. So when I set the time back an hour, it actually sticks while the battery is the only power.
 
No it does not. The time jumps back to DST. You are correct. Can you post your updated code?

Thanks
 
Ahh, good. Thanks for confirming that.

Here's the replacement for set_rtc() that I'm using. I came up with based on the code in cores/teensy4/startup.c and from reading the i.MX RT1060 Processor Reference Manual. The SNVS_HPCR_HP_TS bit is used in the startup code but I couldn't find it in the reference manual; it appeared to be in a block of reserved bits in the register I was looking it (SNVS_HP Control Register on pages 1299-1300). I assume it's what syncs the RTC to the SRTC.
Code:
void rtc_set(unsigned long t)
{
   // stop the RTC
   SNVS_HPCR &= ~(SNVS_HPCR_RTC_EN | SNVS_HPCR_HP_TS);
   while (SNVS_HPCR & SNVS_HPCR_RTC_EN); // wait
   // stop the SRTC
   SNVS_LPCR &= ~SNVS_LPCR_SRTC_ENV;
   while (SNVS_LPCR & SNVS_LPCR_SRTC_ENV); // wait
   // set the SRTC
   SNVS_LPSRTCLR = t << 15;
   SNVS_LPSRTCMR = t >> 17;
   // start the SRTC
   SNVS_LPCR |= SNVS_LPCR_SRTC_ENV;
   while (!(SNVS_LPCR & SNVS_LPCR_SRTC_ENV)); // wait
   // start the RTC and sync it to the SRTC
   SNVS_HPCR |= SNVS_HPCR_RTC_EN | SNVS_HPCR_HP_TS;
}
 
Thanks for the code and the information. I to have been trying to navigate the 1062 RM. You kind of have to bounce back and forth through it. Still trying to figure out how do a software reset without the T4 powering down.

EDIT: Your code works well. Great work:)
 
Last edited:
You're quite welcome; I hope it's useful to you. And of course, we've still got the original problem of the time set during download being ahead by an hour. I'll be interested to see what happens to it tomorrow, once we're clear of the day when it changed.
 
It appears that the loader thinks we're still in DST.

Which operating system are you using? And which version?

Teensy Loader is using the system's C library tzset() function to detect if daylight savings time applies when it tries to sync the RTC to your computer's clock. It's supposed to work on Linux, on Windows, and on Macintosh.

To investigate, I need to know which system you're using. Might also help to know which time zone and country or region your computer is configured to use.
 
I imagine the OP is using a different OS, but I'm using Raspbian Stretch (kernel 4.19.57-v7+) on a RPi 3B. /etc/timezone is set to America/Edmonton. The output of the date command is showing MST.
 
And here's a quick check of the results of tzset()
Code:
$ cat tzcheck.c
#include <stdio.h>
#include <time.h>
int main(int argc,char *argv[])
{
	tzset();
	printf("tzname: %s %s\n",tzname[0],tzname[1]);
	printf("timezone: %ld\n",timezone);
	printf("daylight: %d\n",daylight);
	return 0;
}
$ ./tzcheck
tzname: MST MDT
timezone: 25200
daylight: 1
25200 seconds is 7 hours west of GMT, which is correct for MST.
 
@Paul, I am using Linux, Ardunio 1.8.10 and TD 1.48 Beta 3. Timezone America/Los_Angeles.
 
same bug here on Windows 8, Arduino 1.8.10, Teensyduino 1.48: when I upload a sketch on T4, the time is one hour ahead (timezone here is UTC + 1).
 
I've got the same T4 DST bug running Arduino 1.8.10, Teensyduino 148 with Mac OS Catalina. With the RTC battery disconnected, the T4 resets the date and time to 0, but when I upload an program using the RTC, Serial.println(__TIME__) returns MST, and the RTC returns MDT. POC code below shows difference:

Code:
void setup()
{
  uint32_t t = rtc_get();
  uint8_t ss = t % 60;
  t /= 60;
  uint8_t mm = t % 60;
  t /= 60;
  uint8_t hh = t % 24;

  while (!Serial);
  Serial.println(__TIME__);
  Serial.printf( "%02d:%02d:%02d\n", hh, mm, ss  );
}

void loop() {}
 
I think I'm still hitting this bug. I'm using Arduino 1.8.10, a T4 with today's Teensyduino 1.49-beta5. MacOS 10.15.2, America/Los_Angeles.

Time's TimeTeensy3 prints an hour ahead of the current time, but the __TIME__ macro shows has the tz adjustment. For me, that's PDT instead of PST.

thx for any ideas -- wylbur.
 
I think I'm still hitting this bug.

Any chance an older copy of Teensy Loader has been running this whole time? Click the small Teensy Loader window (since Macs have only a single menu bar), then click Teensy > About to check the version. Is it really 1.49-beta5? If not, just close it and the next time you click Verify or Upload, the 1.49-beta5 copy will be opened.

If any older copy remains running, Arduino will happily use it, as long as it's not "too old". I believe 1.42 is currently the oldest supported for compatibility.
 
Wow! You nailed it. The Teensy loader reported 1.49-beta1, and when I closed & re-uploaded, the timestamp is correct :)

thanks so much -- wylbur.
 
Has anybody noticed that the RTC did not advance one hour? I did a couple of uploads to the T4 and the time is one hour behind. I am using Arduino 1.8.12 and TD 1.5.1.
Disconnected the coin cell and used the Processing sketch to set the time. Time was right. Uploaded a program to the T4 and the time was behind one hour again.

Am I missing something again:)
 
I did an upload on a T4 just now and saw the same thing. It seems that the loader did not recognise that DST has kicked in, and the RTC was set an hour behind.

Arduino 1.8.12
Teensyduino 1.51 linuxarm
Raspbian stretch
 
I did an upload on a T4 just now and saw the same thing. It seems that the loader did not recognise that DST has kicked in, and the RTC was set an hour behind.

Arduino 1.8.12
Teensyduino 1.51 linuxarm
Raspbian stretch

Thanks for double checking me.
I'm sure when Paul gets the time he will fix this.
 
Last edited:
Status
Not open for further replies.
Back
Top