Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 64 of 64

Thread: Over the air updates

  1. #51
    Junior Member
    Join Date
    Dec 2019
    Posts
    6
    Quote Originally Posted by defragster View Post
    Is that in ref to post #48 code? Came working from IDE 1.8.10 install with TD 1.49b1. Yes there is 'THAT' warning about a type I didn't clean up - but it runs to T4 - that is a warning and the right thing ends up happening.

    Didn't say it was a good solution - it would need minimization - the RTC time print is DEBUG extraneous and was added just to see continuity in function and clock ticks across the process.

    To date all notes on issuing reset RESET to T4 seemed to indicate it just triggers the bootloader. If there is one that works "to call a reset register of the CPU (like Teensy 3.2) " - please post ...
    Thanks! It's working well here, after one or two tweaks (and warnings fixed). Slightly modified version is attached. Restarts as expected after a few seconds, then repeats the cycle.
    Attached Files Attached Files
    Last edited by John Miles; 12-04-2019 at 02:35 AM.

  2. #52
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    Yeah - it just needed a cast to stop the warning - it was working so was ignoring that :: setSyncProvider((getExternalTime) Teensy3Clock.get);

    Odd the USB isn't good and right? That should work! No problem on IDE 1.8.10 and TD 1.49b1 or before with T4's here - in fact 11 months since Beta started lots of issues and that was not one

    You might try a 15sec Restore of your T4: start a second timer (optional). power the T4 and press button and watch about 15 seconds and the bootloader light will go off then BLIP once - release the button and it will get a reset to factory state. Maybe something in the process triggered something?

    Not sure what else changed in the code as cpp - DIFF shows lot of white space.

  3. #53
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    Interesting, this line will put a T4 into a state where the reset button won't work - only a power cycle fixes it.

    SNVS_LPCR |= (1 << 6) ; // turn off power

  4. #54
    Junior Member
    Join Date
    Dec 2019
    Posts
    6
    Quote Originally Posted by defragster View Post
    Odd the USB isn't good and right? That should work! No problem on IDE 1.8.10 and TD 1.49b1 or before with T4's here - in fact 11 months since Beta started lots of issues and that was not one You might try a 15sec Restore of your T4: start a second timer (optional). power the T4 and press button and watch about 15 seconds and the bootloader light will go off then BLIP once - release the button and it will get a reset to factory state. Maybe something in the process triggered something?
    I think it's all good. I suspect my speakers were just turned off yesterday, so I didn't hear the USB device disconnecting and reconnecting. It's pretty clear that it's supposed to do that, so I edited my post to remove that comment.

    Not sure what else changed in the code as cpp - DIFF shows lot of white space.
    Not much, mostly just the changes needed to work with my makefile.

    This will be really helpful in conjunction with Jon's recent progress on OTA updates. The fact that the T4 board can now reflash its own firmware and then subsequently restart itself is a bigger deal than it seems at first. Those kinds of features help turn it into a commercial-quality SBC. Awesome work all around.

  5. #55
    Quote Originally Posted by jonr View Post
    Interesting, this line will put a T4 into a state where the reset button won't work - only a power cycle fixes it.

    SNVS_LPCR |= (1 << 6) ; // turn off power
    Yes, this is useful.

  6. #56
    Quote Originally Posted by John Miles View Post
    This will be really helpful in conjunction with Jon's recent progress on OTA updates. The fact that the T4 board can now reflash its own firmware and then subsequently restart itself is a bigger deal than it seems at first. Those kinds of features help turn it into a commercial-quality SBC. Awesome work all around.
    Too complicated for me. I will wait for a CPU reset register version.

  7. #57
    Junior Member
    Join Date
    Dec 2019
    Posts
    6
    Quote Originally Posted by Utak View Post
    Too complicated for me. I will wait for a CPU reset register version.
    Unfortunately I don't think that'll be possible, at least not at the application level. Would be good to be proven wrong on that.

    The SNVS_LPCR register shuts down the whole power management section, which is why it can't be rebooted by the MKL02 when you press the button. The only other global reset mechanisms I could find in the reference manual were the various watchdog registers, which apparently must now be programmed within 255 clock cycles of startup. Meaning, not from within loop()/setup()/main(), but the runtime kernel. Somebody who isn't me will have to do a lot of low-level hacking to get that to work.

  8. #58
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    Yes, there is a need for a simple reboot() in the standard libraries. A reboot is a valid response to some software detected errors.

    Locking up is often a dangerous action and a MCU should be resistant to it. I don't know, maybe that requires an external watchdog.

  9. #59
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    Quote Originally Posted by John Miles View Post
    I think it's all good. I suspect my speakers were just turned off yesterday, so I didn't hear the USB device disconnecting and reconnecting. It's pretty clear that it's supposed to do that, so I edited my post to remove that comment.



    Not much, mostly just the changes needed to work with my makefile.

    This will be really helpful in conjunction with Jon's recent progress on OTA updates. The fact that the T4 board can now reflash its own firmware and then subsequently restart itself is a bigger deal than it seems at first. Those kinds of features help turn it into a commercial-quality SBC. Awesome work all around.
    Good to know nothing 'tweaked' your T4 in the process! I usually have my speakers off too - especially when it sits there beeping over and over 4 times a minute - there are those times that sound is useful though.

    Just FYI: I put a blank file rtcboot.ino in that folder named rtcboot and it worked with an IDE build!

    I build from editor of choice SublimeText using Windows batch file system : github.com/Defragster/Tset Relies on TyCommander to do the programming - but the Batch file CMD line { thanks Frank B } triggers the Arduino IDE Build with the IDE closed - then uses TyCommander as SerMon.

    The system requires finding the INO to build with - but it naturally builds rtcboot.cpp since it is in the folder. Started to add #include in the INO - but then realized the IDE just includes any CPP in the directory so just put to newlines in the blank sketch file.


    I haven't seen the T4 reflash code - that does sound good. This 'reboot/reset' takes 2 secs - but it is automated and works.

    The original code was for much more - so it should refine down to essential 'Restart()' with minimal overhead. I didn't look to do that - but on the WMXZ thread is occurred to me this could be a useful abuse of it. As noted the only question is if the call to rtc_stopAlarm(); is needed in setup() to prevent the odd behavior that was reported in the other thread where this code came from.

  10. #60
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    Quote Originally Posted by jonr View Post
    Yes, there is a need for a simple reboot() in the standard libraries. A reboot is a valid response to some software detected errors.

    Locking up is often a dangerous action and a MCU should be resistant to it. I don't know, maybe that requires an external watchdog.
    Just triggered the overtemp detection and it seems to just halt. Other than this RTC restart that does an automated Power Off and Restart not recalling anything else worked.

    It'll work for now if not best solution - assuming somebody here can streamline the code?

  11. #61
    Junior Member
    Join Date
    Dec 2019
    Posts
    6
    Quote Originally Posted by defragster View Post
    It'll work for now if not best solution - assuming somebody here can streamline the code?
    The basic problem is that the NXP reference manual is terrible. I don't know how anyone ever got this working in the first place, given the quality of the information provided.

    For one thing, many of the accesses to LPCR and LPSR seem to involve bits marked "Reserved," so I can't even begin to tell what's important, what's not important, and what might actually cause trouble later on. I wonder if these registers are documented in an app note somewhere, or perhaps in the NDA'ed security manual?

  12. #62
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,110
    Quote Originally Posted by John Miles View Post
    The basic problem is that the NXP reference manual is terrible. I don't know how anyone ever got this working in the first place, given the quality of the information provided.

    For one thing, many of the accesses to LPCR and LPSR seem to involve bits marked "Reserved," so I can't even begin to tell what's important, what's not important, and what might actually cause trouble later on. I wonder if these registers are documented in an app note somewhere, or perhaps in the NDA'ed security manual?
    The manual is a headache at best. That code was from @WMXZ and whatever it does works - the only oddity in that thread was that Power button shares the Low Power restart segment of the RTC - and they overlap - it seems on Power Off and On residual Sleep setting will still timeout and wake from an Off unexpectedly - that is what lead to the rtc_stopAlarm() in setup to stop that from future interference when that Low Power core is in charge. I'll post back on that thread ...

  13. #63
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    306
    I added a rtcboot based version of "reboot()" to the flasher4 code. Seems to work.

    Would be interesting to see some testing of the RT1060 watchdog features. Not clear to me that the teensy4 is a device you could trust in an environment without the ability to power cycle it. Ideal would be if the MKL02 had an option to act as an external watchdog that could always reboot the RT1060. Should make for a more reliable system.

  14. #64
    Junior Member
    Join Date
    Aug 2019
    Posts
    5
    Hi jonr,

    have been reading this, but your link in the fist msg is broaken:

    >>See the flasher.* code here: https://github.com/Photosynq/Photosy...ter/multispeq1

    If the code is free do you then have a valid link ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •