How to prevent the auto RTC time setting process at upload? (T4.1)

ninja2

ninja2

Well-known member
In this 2017 post Paul details the auto-setting of teensy time at upload, including this:

Fortunately the RTC on Teensy 3.x has a 32 byte memory which is also supported by the battery. I solved this problem by dedicating the last 4 bytes to the RTC startup. When the RTC is found to be uninitialized (presumably between power was off without the coin cell battery keeping the RTC alive), those 4 bytes have random bits which are very unlikely to be the special code. So the startup code initializes the RTC with the stale timestamp, and writes the code to those 4 bytes.

Later when you upload code, and Teensy reboots, the startup code looks at those 4 bytes if the RTC is already running. If they have the special code, then the startup code assumes the RTC must have the wrong time. It reinitializes the RTC with the linker's timestamp of the most recent compile.
Click to expand...

As I understand an equivalent mechanism has been implemented on T4.x as well, and it works fine on my T4.1

Questions:
(1) Presumably there is some equivalent to the 32 byte memory on the T4.1 for those special 4 bytes of unique code. Where are they located, and how to access them ?
(2) is there a way to override, or prevent the auto time setting process at upload?

My second question is because I am using a DS3231 RTC as the sync provider (for more stable/precise time over the longer term). I don't want to risk the PC time at upload interfering with or confusing the RTC time.
 
The RTC Time to T_4.x is set during UPLOAD - not stored in code (with check on static RAM value) as done on the T_3.x's.

There is a way to disable the RTC time setting on upload as it was implemented in the TyCommander/TyQt program:
1716049335166.png


That was exposed somewhere for implementation in TyCommander - though would have to search for it - or if using unlocked T_4's - use TyCommander for Upload and SerMon.
 
If you're using an external RTC (the DS3231), it shouldn't matter what the internal RTC is set to because it's completely separate.

The 32 bytes of non-volatile memory won't hold their values when unpowered because you're not powering the internal RTC.
 
defragster said:
The RTC Time to T_4.x is ... not stored in code (with check on static RAM value) as done on the T_3.x's.
Click to expand...
My RTC_master code works on my UNO R3, R4, Mega, Due, T3.x and T4.1. Some of these have a trusty old DS1307, some with DS3231.
The code auto-detects the RTC type by testing for a 'magic code' I previously wrote into the onboard NVRAM (DS1307) and a different code in the on-module AT24C32 EEPROM (DS3231 module).

Now I want to expand my code to include auto-detection and use of onboard RTC on the T3.5, T3.6 and T4.1. I plan to set up a similar magic code in onboard EEPROM, so I can cover all cases in software:
1) no RTC (onboard or fitted)
2) on-board RTC
3) DS1307
4) DS3231 + AT24C32
Any suggestions/examples for accessing EEPROM on T3 + T4 ? That would be great.
 
Last edited:
jmarsh said:
If you're using an external RTC (the DS3231), it shouldn't matter what the internal RTC is set to because it's completely separate.

The 32 bytes of non-volatile memory won't hold their values when unpowered because you're not powering the internal RTC.
Click to expand...
Before adding a DS3231 module to the T4.1 I played with the on-board RTC and got it running with a backup battery. I then added DS3231 (with the T4.1 battery backup still in place). I figured I should only need to
Code: 
setSyncProvider(RTC.get)
in lieu of
Code: 
setSyncProvider(getTeensy_Time)
and that 'seems' to work, but i can't tell if the time is coming from the PC upload, the on-board RTC or the DS3231. I can remove the T4.1 battery, but I'm keen to expand the auto-detect using software as described above.
 
ninja2 said:
Any suggestions/examples for accessing EEPROM on T3 + T4 ? That would be great.
Click to expand...
The standard Arduino EEPROM library works with T3 and T4, look in the examples menu.
ninja2 said:
Before adding a DS3231 module to the T4.1 I played with the on-board RTC and got it running with a backup battery. I then added DS3231 (with the T4.1 battery backup still in place). I figured I should only need to
Code: 
setSyncProvider(RTC.get)
in lieu of
Code: 
setSyncProvider(getTeensy_Time)
and that 'seems' to work, but i can't tell if the time is coming from the PC upload, the on-board RTC or the DS3231. I can remove the T4.1 battery, but I'm keen to expand the auto-detect using software as described above.
Click to expand...
Set the external RTC time to something different, for example a year ago. Upload a new sketch and see what time is reported.
 
Thanks all for the good info.

@defragster I recall using TyQT when I was first got into teensy back in 2016. If my (suspect) memory serves me right, it was essential back then whereas now it seems more optional ? This thread is an example where it can help, but I'm still hesitant to jump into another tool until I really need to. Perhaps you can convince me to jump sooner? :)
 
@ninja2 - if it was used then how it looks and works is known - it has only been improved since it seemed the best tool to make Teensy better when it comes to SerMon on one or multiple connected units - or a single unit running multiple USB interfaces. The fact that it can integrate and upload to (unlocked) devices is great.
It got the indicated upload without pushing the RTC (on the Options tab) and other features as they came to seem useful - like a 'delegate' command to disconnect from Teensy USB and trigger Teensy.exe for upload to work with LOCKED T_4.x, which of course would not help in this RTC case. It was also made to recognize ESP32 or other type USB devices as a generic SerMon.
It is always 'pinned to taskbar' here - even connecting a USB device just to see what COM port ## it was assigned since it displays that on the Information tab.
And being a stand alone window from Arduino IDE (if used) it can be placed on a second screen rather than on IDE 2.x where it is a sub-window stealing space from code edit space, not being as responsive and not logging all the output to disk for the times that having that is useful.
 
Interesting. I seems the IDE devel. team has been stuck on 2.3.2 for ages and, as we all know, it has a few annoying behaviours (=euphemism)

Can TyQT or TYcommander completely substitute for the IDE?
 
You must log in or register to reply here.
Back
Top