Over the air updates

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.
 

Attachments

  • rtcboot_test.zip
    39.4 KB · Views: 97
Last edited:
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.
 
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
 
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. :cool:
 
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. :cool:

Too complicated for me. I will wait for a CPU reset register version.
 
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.
 
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.
 
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. :cool:

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.
 
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?
 
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?
 
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 ...
 
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.
 
Here is the Teensy 4 version. Several people have used it.
 

Attachments

  • flasher4.zip
    61.5 KB · Views: 189
Ok, as 0x100000 points to space not backed by storage this is not surprising. 0x60100000 works much better ...

Kind regards,
Sebastian
 
I've been trying to make this work for a few days.
I want to eventually send a hex string through can to update the t4 but for not just to try and understand it I'm using a t3.6 to send the intel hex strings to the T4

I created a sketch on the t3.6 to send the data (Basic blink sketch) to the T4
I load the provided example into the T4 change several things around to make it look at Serial1 for data and print errors and such on Serial.
It simply won't work.

Am I doing something wrong?
I also loaded a serial eco sketch and the serial data is received from the t3.6 perfectly so I don't think its wiring or something simple.

Also, we start with memory location 0 correct?

Thanks for any help!
 
Hi bigboosted, all,

I got this to work. In my case I use a Raspberry Pi with Mosquitto, PostgreSql and node-red, a Teensy 4.0 as an mqtt-to-canbus "router", and on the canbus I have a Teensy 3.2 for a 64x64 illuminated street number and a couple of Arduino Nanos for my irrigation system. The Teensy 4.0 mqtthub, and via the mqtthub the Teensy 3.2 streetlight and the Arduino Nano valve controls can have new firmware flashed via node-red.

FWIW, my CAN firmware protocol has three message ids, CONTROL and DATA (sent by the hub) and ACK (returned by the client for every CONTROL and DATA). CONTROL is either BEGIN (containing hub firmware protocol version, memory type - in case of Teensy only flash, and the unique number of the client device), ADDRESS (containing the 32-bit address to continue from) or END (containing the number of frames sent and a 16-bit protocol-level CRC). DATA is up to 8 bytes of data. ACK just positive or negative.

My MQTT firmware protocol is a topic "homie/device/firmware/<client device number>/flash" and a payload in Intel Hex format. I use the PubSubClient library from Nick O'Leary, slightly enhanced to allow reception of big payloads. For CAN communication I use the ACAN library from Pierre Molinaro. I have a function can_receive that handles all the business of the firmware reception and flashing.

The core of your question is the flashing business, I guess. Most what you need you will find in Teensyduino/hardware/teensy/avr/cores/teensy[34]/eeprom.c. Some other stuff here and there on the net. And of course in the Kinetis/NXP processor reference manuals.

I'm lagging behind in more documentation, though. So which kind of challenge are you after? Do you want your obstacles removed one by one by correspondence, or do you prefer a complete solution thrown at you with little-to-none explanation?

Kind regards,
Sebastian
 
Sebastian,

Thanks first off for the response. I do not want something handed to me that I know little about. I want to learn my way through it.

I will look at Teensyduino/hardware/teensy/avr/cores/teensy[34]/eeprom.c as soon as probably tomorrow.

I can handle the can side no problem. I can build a hex array. But I need to figure out how to push that to memory. Then how to move that from the upper half to the lower half and run it. This particular part is what I have little understanding in.

Again thanks
 
Also, we start with memory location 0 correct?

On Teensy 4.0 the flash memory starts at 0x60000000 and has a size of 0x200000. The last 0x10000 are used by Teensyduino for EEPROM emulation and a 4kB know-good LED blink program.

You can compute the amount of flash usage by the current application on the Teensy 4.0 by taking the address of external symbol _flashimagelen.

For further details refer to imxrt1062.ld.

Kind regards,
Sebastian
 
I was able to build a sketch that copies the top half of the memory to the bottom half perfectly.
I know how to erase the top half but how do I make it jump to the lower half and run after that?
Does the line 0x60000000 need a jump command to the new starting address? If so how do I do that?
 
I was able to build a sketch that copies the top half of the memory to the bottom half perfectly.
I know how to erase the top half but how do I make it jump to the lower half and run after that?
Does the line 0x60000000 need a jump command to the new starting address? If so how do I do that?

Jumping to 0x60000000 will probably not work. Have a look at the .lst file that is generated from your code -- at 0x6000000 seems not to reside any proper instructions.

Rather, you could think about calling ResetHandler. Refer to startup.c. But that is reported to work neither, as the processor just is not in the same state as just after a hardware reset.

So what is seemingly working (and I use it successfully) is to use some soft reset feature of the ARM, as decribed in http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Cihcbadd.html (search for "0xE000ED0C") and discussed in http://forum.pjrc.com/threads/24304...)-vs-_restart_Teensyduino()?p=35981#post35981

Kind regards,
Sebastian
 
What I have been able to do it write a sketch that uploads via can a new sketch to the lower half of the memory. Using checksum's as its loading and once completed checked for data integrity again.
Once it is loaded and checked, Erase the upper half, copy the lower to the upper, Erase the lower, and Reboot. It works very well so far.

I only have one T4.0 for now so I send the new file over can from a T3.6. It's nice that the T3.6 can hold an entire file and code for sending this to the T4.0

I guess the danger would be if this was embedded without access to the reset button and then erase/copying from lower to upper failed or stopped for any reason.
At least with the button exposed if anything goes wrong you can load another file via USB. (My outdoor stuff needs to be potted without button or USB access).
 
What I have been able to do it write a sketch that uploads via can a new sketch to the lower half of the memory. Using checksum's as its loading and once completed checked for data integrity again.
Once it is loaded and checked, Erase the upper half, copy the lower to the upper, Erase the lower, and Reboot. It works very well so far.

Congratulations! Sometimes it helps just to know that it is possible, no?

I'm a bit confused what you mean with lower and upper. There is a nice Memory Layout picture in https://www.pjrc.com/store/teensy40.html; you'll see that all regular code is copied into RAM1 at startup, leaving only FLASHMEM code and PROGMEM variables in flash memory. Teensy 4.0 flash starts at 0x60000000 and is 0x200000 in size. So I store the new firmware as received into the region starting at 0x60100000 first ("upper"), then I check, then I move to 0x60000000 ("lower") first erasing pages as I go, then I reboot. I don't bother to erase the "upper" half after copying as I want to make the "copy to lower and reboot" as fast and robust as possible, because indeed if that goes wrong the mechanism could well get stuck and then what's left is to revert to USB programming.

I only have one T4.0 for now so I send the new file over can from a T3.6. It's nice that the T3.6 can hold an entire file and code for sending this to the T4.0

As I'm forwarding the Intel Hex format data as I receive it streamed via MQTT my sender does not need to have the full file in memory.

I guess the danger would be if this was embedded without access to the reset button and then erase/copying from lower to upper failed or stopped for any reason.
At least with the button exposed if anything goes wrong you can load another file via USB. (My outdoor stuff needs to be potted without button or USB access).

Yes, indeed, it's not bullet proof. More robust designs (companion uC talking CAN etc.) are surely possible, but also require a bit more effort.

Kind regards,
Sebastian
 
Back
Top