OTA update alternative

Status
Not open for further replies.

someteen

Well-known member
Hello,

I need a quick solution for a project (a small robot) but I should be able to reprogramm it over the air.

As I'm a big fan of Teensy boards, I'll use one of them (Teensy 3.2) but, as far as I've read, there's no OTA sketch uploading available (due to locked bootstrap or something).

ls there any other alternative? Like installing a NodeMCU + Lua or a RTOS?

As I don't really need to reset the device everytime I need to reprogram it, I thought of just "refreshing" a small part of it (an algorithm/procedure) to tweak some sensor inputs and to adjust some actions (driving the motors).

As an emergency solution, I am thinking of some sort of client/server operation, where the Teensy board will have a "read-only" firmware (for simple commands like reading the sensors and driving the motors) then I'll use a Raspberry Pi to do the math and to control the Teensy actions (through a python script or something).

I could have used the RPi alone for that matter but I need a low power MCU on that robot. Btw, I have some ESP8266 and RF24 boards available for the wireless support.

Any help is greatly appreciated, as it supposed to be a Christmas gift for my son (and an introduction to embedded world). ;)
 
utasker is the off the shelf solution
http://www.utasker.com/forum/index.php?topic=1869.0
Though you do need to get a free project licesne to go that route. It's also possible to roll your own code based on some of the examples of people who have made self modifing code, just don't do it with your actual finished project until you know it's not going to over write anything critical while it runs and bricks your Teensy, which is a very real possibility when you try this.

One less pretty option but possibly fast to setup option is to use the Pi as a host for the Teensy loader command line tool. Running full Arduinio + Teensyduino is still an adventure on a PI, but your use case the command line loader only may work to deliver a Pi programing station you can remote into, drop new hex files on and then have the user connect up the bot via USB and get new code onto it.

Still not as elegant as an organic OTA update would be though.
 
Do you have any further references for modifying the code on the fly? Like sending a serial string to the Teensy (over the radio) containing a new content for a program function then let the Teensy use the updated content of that function? This is what I am after, mainly.

Using a portable RPi is not an option (I could have used the existing notebook used for coding) but, usually, the robot will "walk" away (line follower, wall detection) hence it's not comfortable to keep on following him for every reprogramming step.
 
You could use the ESP8266 as a UART bridge to pass data between the pc and the Teensy. Here is a ESP8266 add-on board specifically made for the Teensy 3.2.
 
That could be done - but there isn't (yet?) official support for that. The file would need to be received/saved and then passed off using one of the other 'outside' methods. FrankB did a test of concept writing from an SD flash card - but it only got as far as being able to fill half of the program space as I was looking at it and development stopped AFAIK.
 
Thanks, I have used ESP8266 before but my question was if you can upload a sketch on a Teensy board through the ESP8266 wireless interface.

What about dynamically changing the content of a function/subroutine? I remember I once used a programming language (some sort of Basic, I presume.. or Fox?) where you could dynamically construct a program statement at runtime by concatenating strings variables.

By example, you could have a block of code like this:

String a = "Serial";
String b = ".Print(";
String c = ");";
String myCommand = a + b + "Hello world!" + c;
execute(myCommand);

So, is there any method to replace the content of a function at runtime (like rewriting the memory blocks where that function are stored)?

Like I've said, in my application it might be necessary to only change a small portion of the code (a subroutine) hence it would be better if I could avoid a sketch upload/MCU restart anyway. Just sending the new subroutine content through serial interface then let the MCU reload the new content into the memory. Could it be possible?
 
OTA Not done in any PJRC supported way I've seen.

As far as programming - you can do anything compiled c/cpp allows as supported by the toolset in use. As far as a dynamic sample as indicated - I think that would need a custom run time 'interpreter' for these portions. I wrote one 30 years back to allow folks building and controlling a printing press with PLC's to edit a list of logic that would allow them to provide machine specific operator feedback/warnings from the computer without having to edit the computer code directly.

The code stored on Teensy flash can only be edited after a complete flash erase as I understand it - so without sending in a full new binary - on the fly coding updates would have to come from an outside source.
 
I see, most probably the dynamic code I was talking about was using a runtime interpreter (Basic).

But what about rewriting a memory region, where a function content is stored (kinda 30 years ago peek/poke)?

By using a RTOS (I have no experience with), could you dynamically load/restart a single routine/"script" at runtime without restarting the machine (MCU)?
 
I see, most probably the dynamic code I was talking about was using a runtime interpreter (Basic).

But what about rewriting a memory region, where a function content is stored (kinda 30 years ago peek/poke)?

By using a RTOS (I have no experience with), could you dynamically load/restart a single routine/"script" at runtime without restarting the machine (MCU)?

Yes, most likely interpreted not compiled code you saw.

There is a limited amount of EEPROM on a Teensy you could use for tables or other structures to drive/feed your code at runtime. But the program/data storage area is fixed at runtime. It would have to come from external EEPROM/FLASH/SD or other fixed but changeable elements outside the processor.

RTOS could selectively perhaps chose active routines to enable - but those routines would be fixed at compile time and could only be programmed to respond to 'data' as presented.
 
Why would you go through all this trouble just to tweak some parameters? Make your sketch parse these parameters through UART and use a transparent wireless UART bridge like an Xbee. Only a couple of minutes work.
 
You're right, looks like it's the only feasible alternative left (I was talking about it in my first post, too).

Anyway, it's disappointing to realize that every 2 cent "smartphone" could do OTA updates since years but you can't get a mighty embedding MCU to do it in these days. Sincerely, I was convinced that the new Teensy upgrades (3.5/3.6) would accomplish this task (by using an optional radio add-on of choice - Wifi, RF24, Xbee and so on) but I was wrong.

I've searched the internet for an easy, cheap and power conservative solution to build a small OTA updated project and I found.. nothing. What's all this IoT about? The ESP8266 module itself is too featureless (GPIO wise) to be used alone. A wifi Teensy should be a killer project but, unfortunatelly, Paul is doing it with very small steps (the "brand new" Ethernet interface seems outdated already).

I guess the final solution (for my project) would be a Teensy LC + RF24 module on the robot side, as a low power sensor (and motor/actuator drivers) radio interface and another similar combo (or a RPi + RF24 one, for added connectivity/nodejs host) as a remote/OTA programmable "brain".
 
Last edited:
Anyway, it's disappointing to realize that every 2 cent "smartphone" could do OTA updates since years but you can't get a mighty embedding MCU to do it in these days.

Maybe combine the MCU with a 2-cent "smartphone".

More seriously, did you look into uTaskers approach (ling given by GremlinWrangler)?

If that is not good for you, you can easily write your own secondary bootloader. Using the info you find here on this forum, it should not be difficult.
 
Anyway, it's disappointing to realize that every 2 cent "smartphone" could do OTA updates since years but you can't get a mighty embedding MCU to do it in these days.
Hm, i'd like to buy some of these 2 cent smartphones - where can i get them ?

Sincerely, I was convinced that the new Teensy upgrades (3.5/3.6) would accomplish this task (by using an optional radio add-on of choice - Wifi, RF24, Xbee and so on) but I was wrong.
Yes, wrong. But why did you think that new hardware can do this ?

I've searched the internet for an easy, cheap and power conservative solution to build a small OTA updated project and I found.. nothing. What's all this IoT about?
Not OTA updates, obviously :) Looks like, that only a few poeple need it - for line-following robots ? :)

A wifi Teensy should be a killer project but, unfortunatelly, Paul is doing it with very small steps (the "brand new" Ethernet interface seems outdated already).

Yes, software-development is a time-consuming task. If you want to make a good job.
 
You're right, looks like it's the only feasible alternative left (I was talking about it in my first post, too).

Anyway, it's disappointing to realize that every 2 cent "smartphone" could do OTA updates since years but you can't get a mighty embedding MCU to do it in these days. Sincerely, I was convinced that the new Teensy upgrades (3.5/3.6) would accomplish this task (by using an optional radio add-on of choice - Wifi, RF24, Xbee and so on) but I was wrong.

I've searched the internet for an easy, cheap and power conservative solution to build a small OTA updated project and I found.. nothing. What's all this IoT about? The ESP8266 module itself is too featureless (GPIO wise) to be used alone. A wifi Teensy should be a killer project but, unfortunatelly, Paul is doing it with very small steps (the "brand new" Ethernet interface seems outdated already).

I guess the final solution (for my project) would be a Teensy LC + RF24 module on the robot side, as a low power sensor (and motor/actuator drivers) radio interface and another similar combo (or a RPi + RF24 one, for added connectivity/nodejs host) as a remote/OTA programmable "brain".


It was always the only feasible option. Reprogramming an MCU just to change some variables is very bad engineering. If the variables need to be changeable during runtime, you should implement proper communication features to convey these adjustments.

Furthermore, IoT isn't about OTA. It's about big numbers of cheap, low-power devices communicating very little data at very low speeds.

The OTA debate has been conducted here multiple times, but for most Teensy users and uses cases there is no real advantage nor a need for it. The focus of Teensy is on powerful hardware and efficient ways to use this hardware (e.g. libraries). A lot of Teensy projects are semi-professional (at least the ones that are not educational) and are used in professional environments, where wifi isn't an option. Development happens locally, until the developer is confident enough that the firmware is production ready and it can be rolled out.
It would also require an OTA platform, a time and money consuming endeavor. I think most Teensy users, myself included, rather see Paul spending his time on developing or improving support for low-level hardware features than on a OTA service.

If you're looking for decent OTA support you should check the Particle Photon. This is a product where the emphasis is on easy OTA updates. Consequently the hardware and libraries are sub-par compared to Teensy. You can't have everything :) .
 
I second Frank! Would love to get that 2 cent smarphones. New Apple Iphone is maybe starting at about $650!

As for Small board that you can update over the air? Have you looked at Intel Edison? Not necessarily recommending it, but can be updated over the air. Can run Arduino program...

For me with Robots, I have run them directly using Teensy or I end up with Teensy connected to Linux board, such as an RPI, or more likely Odroid or UP... So you can always connect the Teensy up to one of the USB ports on the Linux board, then from Linux update your Teensy over the air. I have done this a few different ways. Either build on PC, download file to Linux box(WinSCP) and run simple loader program on KiTTY(PuTTY) window. Or I can start up a VNC server on the Linux board, then use something like VNC-Viewer on my PC and then run Arduino on the Linux board...

Also not recommended, but a long long long time ago, I used to work on Datapoint computers which the first one had a processor on it that was developed and then turned into the Intel 8008...
Anyway it was mutliterminal setup, which we did not want to shutdown to update to run different things, so we built in a simple overlay loader, and reserved something some small amount of memory for and then we would load different code overlays into this and then call off to these routines... We had assembled the routines... Not recommended but something like this is probably doable here as well...
 
I get your points, but you must admit that implementing OTA for Teensy modules is not a question of hardware nor a software limitation. It's all about that locked bootloader and that's where Paul has all the answers.

Regarding the "useless" feature named OTA.. I bet a large majority of Teensy/IoT projects are located in remote locations or not having an accessible USB port. Even for the rest of the applications, you can't deny that such a convenient (and time saving) procedure as OTA updating is welcome.

The global trend is to extend the wireless communications anyway (NFC, contactless payments, wireless charging and so on).

Back to the Teensy projects.. how many customers are able to update by hand (Arduino/PC) an embedded Teensy board? Moreover, if the project has radio connectivity, what's the point of not using it?

And no, IoT it's not about small remote sensors.. it's all about "internet" and a simple USB port has nothing to do with it.

The whole discussion looks like the eternal flame of "command line versus GUI". Yeap, OTA means using a GUI for your projects.. you can blame me for that, but instead of running all my life with an USB cable in my pocket I prefer to spend my time in a more pleasant way.

I've read all those threads about OTA updating and I've seen a large interest on this issue. I still don't get the point about its unavailability except for the presumed vulnerability of Paul's bootloader code.

@KurtE:

The RPi is overkill for a small robot. I was thinking of it at first (even at Zero model) but they all are power hogs when it comes to a small robot lightweight battery. Teensy is just the right hardware for that but I can't easily overcome that wired updating procedure.

Btw, I was talking about 2 cents smartphones not the 650$ iPhone! I don't even remember having a phone (except for Nokia 3110) without support for OTA updating. Comparing to the other features of any dirty cheap smartphone, isn't the OTA update just a stupid joke?!

@Frank B, KurtE:

Please leave your addresses.. I have tons of retired "OTA updating" phones in my basement. ;)
 
Last edited:
Pauls's bootloader code does not matter - some posts above you got an example (utasker).
If that does not match your needs, you can write your own. Everybody can do this....
Well, after studying all the needed documents.
So, please, contribute to the open-source community! (instead of consuming only.. :)

Edit:
And, yes, i wrote my own. Just for fun. It is not stable enough to publish it.
As i don't need it, i do not work on it anymore, and i do not want to publish it. There's a risk to "brick" the teensy if something goes wrong in the right moment..
Today, i'd choose a better approach - but as i said - i don't need an other bootloader.
 
Last edited:
So, please, contribute to the open-source community! (instead of consuming only)

And, yes, i wrote my own [..] and i do not want to publish it.

Please, Frank.. contribute! ;)

There's a risk to "brick" the teensy if something goes wrong in the right moment.

I really don't get it. How could anyone brick the Teensy if he's not modifying the bootloader? You could end up with a broken sketch but, after restart, the bootloader should sense that and enter programming mode or you manually press that button to enable it.

I don't need an other bootloader.

Me neither, but there's no chance for OTA uploading otherway. uTasker it's a non-option for an educational purpose application. Why not a Teensyduino menu branch like this:

"Upload -> OTA -> Select network interface"??
 
I really don't get it. How could anyone brick the Teensy if he's not modifying the bootloader? You could end up with a broken sketch but, after restart, the bootloader should sense that and enter programming mode or you manually press that button to enable it.

If you search the forum on this topic, you will find that there is a location in the flash, which, when set properly, may disable any reprogramming of your teensy, i.e. it transforms a teensy into "execute-only-MCU". I'm not sure if you want this. Apart from that a secondary bootloader is possible (after reading a lot of documentation or other peoples program)
 
Regarding the "useless" feature named OTA.. I bet a large majority of Teensy/IoT projects are located in remote locations or not having an accessible USB port. Even for the rest of the applications, you can't deny that such a convenient (and time saving) procedure as OTA updating is welcome.
Most Teensy/IoT projects are located in remote locations not having a usable connection to do firmware updates.

No one is saying OTA is useless, just that there are more important and useful features to work on right now. More efficient I2C or transparent DMA might not sound as sexy as OTA, but for most Teensy projects this has more value than eliminating the need for a USB cable.
 
If you search the forum on this topic, you will find that there is a location in the flash, which, when set properly, may disable any reprogramming of your teensy, i.e. it transforms a teensy into "execute-only-MCU". I'm not sure if you want this. Apart from that a secondary bootloader is possible (after reading a lot of documentation or other peoples program)

I thought @Frank B was talking about a power failure during uploading that could eventualy brick the Teensy board. Using a buggy update procedure (erratically rewriting the flash blocks) it's a completely different story.

Anyway, the trend here seems not to welcome such a feature so I rest my case. A two dollars RF24 module should solve my problem for now. I'm looking forward for the NFC updating anyway.. ;)

PS: If someone (Frank?) wants to help me with a common grounds for starting such a project (without adding extra hardware for storage, like SD card or flash chips) I will gladly share my results.

Later edit:

Sorry, @Frank, I missed your latest post (I was writing my message). I'll check the link and I'll further ask for help. Thank you very much for your time.
 
Last edited:
Indeed - Paul has noted PJRC support for OTA is somewhere on his list - but then the T_3.2 and PROP Shields and T_3.5 and T_3.6 and perpetual Arduino IDE updates and TeensyDuino Updates to track Arduino and hardware and software changes have all followed. And of course a WiKi and PJRC.com and a new Forum platform are on that list with Audio and other core system features that the T_3.2 uses as well as all the extended hardware of the new K64 and K66 that need to be made functional or full featured - Ethernet, 2nd USB, SDIO - plus whatever other list items noted or not - including the K64/K66 reference board and stocking the Programmer MCU's. Oh and Hardware Debugging support.

It works on $5 ESP-8266 - (or a 2 cent smartphone with a $20+/mon contracted carrier) but they have external flash/storage where OTA binaries can be written safely and then under hardware control the ESP can swap in the new binary. On the Teensy processor the Flash is read only until under control of a RAM or external programmer and is Flash or Fail with the odd chance of bricking the unit beyond recovery of the external onboard Teensy programmer MCU to recover.

It seems important elements are coming into place for PJRC to safely support this - The T_3.5/3.6 have the 15 second button MCU reset (perhaps helpful if an OTA fails oddly) and the those and T_3.2 got extra LDO power to support bolting on an ESP_8266 or other external device to bring in and store the OTA binary in a way that ideally will work reliably to get/store and transmit a valid binary to get pushed to the Teensy MCU, perhaps with help from a more capable (larger code capacity?) onboard programmer MCU . . .
 
Someteen: Link: Oh that's nothing special.

You should begin with reading the chapter regarding the flash controller. (kinetis reference manual). But don't miss the flash-config-area... and buy some spare Teensys before :)
 
Last edited:
@Frank B, @defragster:

I've just came across few of yours github repositories:

https://github.com/Defragster/ArduinoTeensyESP8266

https://github.com/Defragster/Arduino-Teensy3-Flash

As far as I have read, they are Teensy OTA related projects (ArduinoOTA forks). Is there a fail-safe version to download/test?

Btw, if you don't have enough flash to store the new hex, what about rewriting the flash on the fly, by sending its content (over the air) in small chunks? It might be unreliable, but you still have the option to correct any errors by using the USB port uploading procedure.

After all, sh*t may happen even when you're using wires (I had such a weird experiences while using some cheap USB cords).
 
Status
Not open for further replies.
Back
Top