Teensy Bootloader Change

[Defragster]

At least in the Teensy 4 during programming the TeensyLoader passes the current system time to the RTC setting it at the time of programming.

The old hard to replicate across build systems mechanism of stuffing 'compile time' in the is not used on the T4. Assuming this will carry over to the T_3.x family with RTC's ?

Tytools will need to replicate this mechanism.

[Defragster]

I don't see that PJRC released a sample to this yet in the cmdline version. And no forum response.

[Koromix]

See #46 for some info about this.

[Defragster]

Put this issue in for PJRC:

PaulStoffregen/teensy_loader_cli#53

[mecparts]

I see this one's been around for a while, but is there still any interest? Out of curiosity, I sat down with Wireshark and usbmon today and figured out what the GUI loader was doing to set the Teensy4's SRTC when it uploaded the code. I can write up some notes if it'd be of any interest.

[Defragster]

That would be interesting - then @Koromix could look into it. PJRC hasn't posted code yet showing the process.

Note: It needs a way to disable auto setting - as PJRC does it if a device has a local time already it gets set it seems based on a forum post where that was not desired.

[mecparts]

After the loader has finished sending the code, it sends a buffer with the address set to 0x00FFFFFF, which Halfkay sees as a "reset the Teensy4" command.

Normally, the data in this block after the address is zeroed out. But if some of the bytes are set to certain values, the SRTC will be set.

With buf[0..2] set to 0xFF, if buf[64..67] are set to {0xB7, 0x31, 0xC2, 0x89}, then the next 8 bytes (buf[68..75]) are interpreted as the 2 longs that SNVS_LPSTRCLR & SNVS_LPSRTCMR will be set to (buf[68..71] -> SNVS_LPSTRCLR, buf[72..75] -> SNVS_LPSRTCMR) to set the SRTC.

Assuming that buf[] has been zeroed out, the following Q&D code fragment will set the buffer up to command Halfkay to set the SRTC to the current UTC time and then reset the Teensy4.

   time_t now = time(NULL);
   unsigned long hi,lo;
   lo = now << 15;
   hi = now >> 17;
   buf[0] = 0xFF;
   buf[1] = 0xFF;
   buf[2] = 0xFF;

   // magic numbers???
   buf[64] = 0xB7;
   buf[65] = 0x31;
   buf[66] = 0xC2;
   buf[67] = 0x89;

   buf[68] = lo & 0xFF;
   buf[69] = (lo >> 8) & 0xFF;
   buf[70] = (lo >> 16) & 0xFF;
   buf[71] = (lo >> 24) & 0xFF;

   buf[72] = hi & 0xFF;
   buf[73] = (hi >> 8) & 0xFF;
   buf[74] = (hi >> 16) & 0xFF;
   buf[75] = (hi >> 24) & 0xFF;

I don't know what the 4 bytes at buf[64..67] do, but the GUI loader sends the same values for both Teensy4.0 and Teensy 4.1.

There'd be a bit more code involved in sending the local time rather than the UTC time, but not a lot.

I agree that it would be handy to have some way of saying "only set the time if the Teensy's SRTC isn't already running". But I don't know how we'd know that from the PC side of things. Could be there's a flag in the magic numbers; could be there isn't. Short of that, a command option on the PC side to set the time only when requested to might be the best that can be done.

[Defragster]

Good work @mecparts . Interesting tool!

The setting in TyCommander would be Yes/No to send the time update. Currently it doesn't so having a way to preserve that would allow folks needing time left unchanged to continue like that?

Currently the upload passes local time as I've observed it - unless the sketch had a UTC to local offset programmed.

[luni64]

Cool, I'll implement this in TeensySharp and give it a try. Would be interesting if it works without doing the full erase first. I.e. just setting the time without uploading the firmware...

[mecparts]

Currently the upload passes local time as I've observed it - unless the sketch had a UTC to local offset programmed.

Yes, the GUI loader sends the local time, so it would be good to duplicate that behaviour.

[mecparts]

Would be interesting if it works without doing the full erase first. I.e. just setting the time without uploading the firmware...

I just tried that out (with the -b option of teensy_loader_cli) and yes, it does just set the time without uploading any firmware.

[mecparts]

For Linux at least, the UTC time_t value can be converted to local time (observing DST when it's in effect) with the following code fragment:

   time_t now = time(NULL);
   struct tm *ti;
   ti = localtime(&now);
   now += ti->tm_gmtoff;

It'd be great if that same non-standard extension to the tm struct existed in MacOS & Windows, but I have no idea if it actually does.

[Defragster]

I just found this to work: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-localtime32-localtime64?view=msvc-160

Not sure what happens with DST - Paul had to reconfig for it after release.

That says that func deprecated used code in this link : https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localtime-s-localtime32-s-localtime64-s?view=msvc-160

    struct tm newtime;
    __time64_t long_time;
    // Get time as 64-bit integer.
    _time64( &long_time );
    // Convert to local time.
    _localtime64_s( &newtime, &long_time );

[luni64]

I tried it, works nicely! However, I don't want to hijack @Koromix issue for this and opened a discussion in the TeensySharp repo luni64/TeensySharp#5 showing the used code and a demo video.

Thanks @mecparts and @Defragster

[Defragster]

@Koromix - I followed @luni64's link and using that code it worked to set time on a T_4.1.

[Koromix]

Nice work! Thanks, it saves me quite some time for this feature :)
I'll add a simple version (maybe without a setting to disable it) this week.

[Koromix]

Ok, I've added this in the latest couple commits.
Win64 build available here: https://koromix.dev/files/tytools/

Next commit this week will add a GUI setting to disable RTC change.

[Koromix]

Actually, I'm thinking of a setting with 3 values: set to UTC, set to local time, don't set.

[mecparts]

I'm glad to hear that it's worked out.

[Koromix]

Yes, thanks a lot :)

[Defragster]

Great to finally have this coming to working. Great work decoding it without the PJRC published code and glad getting it into TyTools working. The three options seem good.

Mention:: @KurtE @mjs513

[Koromix]

New build to fix crashes: https://koromix.dev/files/tytools/

[Defragster]

Just tested 'fix crashes' build to work on T_4.0 and 4.1 and set the correct Local PC time!

Just noting : not seeing UI for selective time passing ...

Also quick note: TyCommander is awesome to use. Putting the same sketch to 4.1 then because of the unique name when built for T_4.0 asks for the device as it does not match the associated name - Very cool when 'Integrated to Arduino'!

TimeTeensy3.ino.TEENSY40.hex
TimeTeensy3.ino.TEENSY41.hex

[Koromix]

Yeah the UI is not there yet, it'll come later this week (busy week) :)

[Defragster]

Sounds great and nice TimeSet is in there. Saw lots of notes from github clearing issues - thought maybe you had a day off :)

Haven't been using TIME - but now it is available the Local Time is a good default until options can be added.

@FrankBoesing

[Koromix]

The latest build allows you to change the RTC mode per-board: local time, UTC, or ignore.

You can find these builds here: https://koromix.dev/files/tytools/

[Defragster]

Good work Niels.

This is a separate issue - but now in Beta is a LOCKED T_4.x that uses encrypted .eHex instead of the .hex. It has unique conversation with 'bootloader'.

These will be a duff part order and not common - but TyComm won't be able to program these as it stands.

[Koromix]

Thanks for the report, can you create a new report with some info and links about this Teensy 4.x encryption system?

[Defragster]

Nothing you can do yet. So far in Beta only the PJRC Teensy.exe code knows the process. Hopefully the command line code will be updated and published and maybe you can replicate the steps. It is very 'process critical' it seems as even the bootloader has to work hard to talk to an encrypted 1062.

I've been making it work - but TyCommander cannot be integrated to IDE - unless the 'delegate' option was used? So far I've only used that in my TSET command line work. I'll see if I can 'see steps' for making it work ...

I'll make a placeholder issue for now