View Full Version : Wireless (remote) programming of Teensy 3.0?

06-05-2013, 06:15 AM
I'd like to be able to wirelessly (using XBee's) program my Teensy 3.0 - similar to what the AdaFruit tutorial describes here (http://www.ladyada.net/make/xbee/arduino.html) for Arduino's. The idea is to have an LED display outdoors that I can update periodically without going outside, pulling the board, re-programming inside, then redeploying outside. (I did that all last Christmas season... in the rain... :) )

I've done it with an Arduino Duemilanove but I'm not sure how to attack the problem with a Teensy 3.0. Specific questions: Does the Teensy reset pin work similarly to the Arduino Duemilanove (pulling it low causes a reset)? After reset, does the bootloader wait for code, just like the Arduino, for a period of time? Can I send code in over one of the serial pins (seems like the answer to that might be no)?

Anybody tried it? Any pointers or direction on what I should try?



06-05-2013, 07:57 PM
Teensy programming is only by USB. Serial-based programming isn't supported, so this approach can't work.

06-05-2013, 11:32 PM
Teensy programming is only by USB. Serial-based programming isn't supported, so this approach can't work.

Thanks Paul, I kind of suspected that. I love my Teensy and would really like to find some way to upload code remotely. Any ideas for alternate approaches? I'm willing to do some work.

Since I talk to the XBee via USB on the computer side using this (https://www.sparkfun.com/products/8687), perhaps there's a way to get the receiving side to do the opposite and take the serial XBee data and convert to USB to send to the Teensy? (clearly not my area of expertise)



06-06-2013, 08:19 PM
While not the ideal solution, for 35$ + 10 $ for a wifi adapter you can get a rapberry pi and connect it to your Teensy to reprogram it remotely.
I've been using this with a couple of Arduinos and it works like a charm !

06-06-2013, 08:48 PM
This request has come up several times... so I'm considering what I might be able to do on a future version. It will require the bootloader in the Mini54 chip to also listen on a serial port, probably Serial3. One side-effect of activating Serial3 would be the TX3 pin will become an output while programming, which could be a pretty substantial issue for people using that pin for other stuff. There probably needs to be some way to not enable the serial transmit pin unless absolutely necessary. Another issue would be how to enter bootloader mode. Maybe one of the XBee pins would need to be wired to the PROG pin to initiate loader mode? These and other issues would need to be figured out pretty well before I could even attempt a new version of Teensy with support for this type of wireless reprogramming.

06-07-2013, 02:28 AM
While not the ideal solution, for 35$ + 10 $ for a wifi adapter you can get a rapberry pi and connect it to your Teensy to reprogram it remotely.
I've been using this with a couple of Arduinos and it works like a charm !

nlecaude - Now that's a creative approach. Seems funny to deploy a whole raspberry pi just to get remote programming but sometimes you do what you have to do! Can you point me to any info on how people have done this (even if it's with an Arduino)?


06-07-2013, 03:16 AM
I'm assuming I'd be able to enter bootloader mode by taking the reset pin low using the same circuit that the Adafruit tutorial (http://www.ladyada.net/make/xbee/arduino.html) uses. True? I can't find what the PROG pin does but based on your question, I'm guessing it does something similar or perhaps needs to be held low while programming?

01-30-2014, 08:56 PM
Where does this stand? We have a project that will have 84 Teensy's and they will be hard to get to for repropramming after they are installed. Currently planning on RS485 comm for interaction and would love to be able to use that in some fashion to load/modify code.

01-30-2014, 10:20 PM
On an ARM7, I wrote a secondary loader (SL) that downloaded updates to config data and/or new code, in .hex form, wirelessly. The SL was stored in a portion (sector) of flash. The app code was stored in other sectors. The SL erased the app's sectors as needed. Allowed for unattended updates and status reporting remotely.

I did an in-place flash rewrite with automatic unattended restart on comms error - because the downloaded code was larger than RAM and there was no mass storage like an SD card.

The bug-a-boo:
If I recall correctly, there's a constraint (?) with the Freescale (or Teensy's loader) where to write any portion of flash, one must first erase all of flash and that would include the area where an SL is installed. I suppose the SL could be coded in position independent code (a compiler option?) and copied to RAM before erasing and re-writing flash as the download progresses. The SL could rewrite itself from RAM back to flash if need be. And so on. The trick is to make this bullet-proof to comms errors. In my case, that was essential in order to not get on airplanes to many sites.

01-31-2014, 04:51 AM
How about programming the Teensy with an interpreter? You would be able to update the behavior by transmitting new code in the form of a sequence of byte codes, a table, or a script.

There's a bunch of interpreters here: http://www.pjrc.com/teensy/languages.html

My Morse code PDA has a very simple interpreter with a command line interface.

It's really easy to write your own. Here's a rough sketch:

while (1) {
cmd = get_next_command();
switch (cmd) {
case LIGHT1_ON: digitalWrite(LIGHT1, HIGH); break
case LIGHT1_OFF: ...
case LOAD_PROGRAM: ...

01-31-2014, 06:43 AM
I ended up deploying a Raspberry Pi with my Teensy as nlecaude suggested. Works well for my application although it's a pricey solution.

03-06-2015, 01:39 AM
Sorry to resurrect an old thread... I would be really keen to be able to program the teensy via a uart, instead of the usb. I'd like to put in a Bluetooth LE module, and have it reprogram the board so that you can reprogram it from an iPad app.

03-06-2015, 02:47 AM
As was noted above the 'unbrickable' architecture used for the Teensy constrains it to programming via USB. There are a range of AVR based solutions that natively support wireless re-programing but at this time nobody has invested the major effort to find a 100% reliable method, redesign the boards to maintain compatibility and then rebuild the ARM bootloader to make this all happen on a Teensy.

None of the above is impossible and hopefully will show up in some future design but it's not something that will magically pop up as a software patch for your existing boards as far as I understand things.

03-06-2015, 07:50 AM
Hi, thanks for responding. I need to use something as powerful as the Cortex-M4, but as I've done more research I've realised that reprogramming the device as frequently as my application would require would be detrimental to the lifetime of the chip. I'm trying to build a field-programmable audio effect processor. I'm looking into how possible it would be to write a small kernel to handle I/O, but load DSP programs from an external SRAM chip or something. I'll post a new thread about that though.

03-06-2015, 04:59 PM
I vote for Teensy's bootloader to optionally avoid erasing n high-address flash sectors (excluding the one used for non-volatile data), and run code in that area if present, at power-up.

So as to not burden PJRC, the user community would put various bootloader types there - using whatever medium to do the non-USB download. Such as various wireless radios, CAN, SPI, I2C.
Or simpler and better and as others do, have a $1 SPI Flash memory chip as a piggy-back board and this secondary bootloader would get the new main program from that and flash it. That way, the download medium that got and wrote new code to the SPI flash can be user-specific - i.e., the download and write-to-SPI flash is a user app, not part of a bootloader. The bootloader would always look to see if new code is in flash. I and others have code for this scenario.

Perhaps there has to be a white-list (registered CRCs?) of who authored what code that goes in that space, as an anti-counterfeit strategy for PJRC's protection.

PS: There are other-brand M4s with a ROM bootloader that auto-detects download attempts via USB/DFU, UART, CAN, SPI, etc. This code space could also accommodate a wireless downloader for a variety of radio types. But not K20s, I suppose.

03-06-2015, 07:32 PM
Given the Teensy can run instructions that are located in normal read/write memory, an alternative to rewriting the whole flash occurs to me is to use a fixed area of memory to run your dynamic code from. You would download the code to this memory, and jump to it. Because you don't have the whole infrastructure for shared libraries, you would have to setup a class that has function pointers or virtual functions for each of the functions that the dynamic function can call, and pointers for the structures.

You would have an agreed upon entry point that contains a jump to the actual function to start at, and that function would be passed the pointer to the above class to use. Because read/write memory is not saved across calls, I would suspect you would want to include an EEPROM memory chip or a micro SD card to hold the instructions, and at power up, the static portion of the code would read the instructions into the buffer and jump to it.

Then in your code, you would have a bluetooth chip that you check if there is any data. If there is data, you then read from the bluetooth device and save the bytes to your permanent storage area. When you have the full data, you would then read it into memory and call it with the class pointer. For safety's sake, I would have two areas in the EEPROM/sd card, and an indication which bank to use. When you are reading the bytes, you would write to the alternative bank, and once you have a complete image transferred, then update the bank pointer, and restart (so if the transmission drops, you can still run from the last good image). Perhaps having a third bank that is the initial code, that is used when a switch is set when you reboot.

Obviously, you would have to do the developing of this code outside of the Arduino IDE, and you will have to write your own linker scripts to put stuff in the right location, etc.

Frank B
03-06-2015, 07:51 PM
I have some code, it reads from SD-card, flashes it to the upper half of flashmem, and then i a second step it copies the the upper half to the lower half and then resets the teensy.
Tested only with 3.1 and it's only a "study" so far, but it works good for me. The main code can be changed to use an other source than SD-card. Serial for example. And of course it can be changed to use an other buffer, SPI-Flash or SPI-RAM.
IT's NOT for beginners, because there is a risk that you brick your teensy if you do not know what you do. If you want to look at it, it's at my github-account. But please do not complain if you successfully bricked your teensy :-)

05-16-2018, 02:08 AM
While not the ideal solution, for 35$ + 10 $ for a wifi adapter you can get a rapberry pi and connect it to your Teensy to reprogram it remotely.
I've been using this with a couple of Arduinos and it works like a charm !


I have this same problem, and would love to solve it - even at the cost of an additional $45. Can you please point me to any documentation on this method?

I'm a reasonably competent EE & programmer, but I have never dealt with the Raspberry world



05-16-2018, 02:39 AM
RPI programs teensy over USB, but I heard the programming is very slow

05-16-2018, 02:49 AM
So, the Raspberry Pi becomes the USB host for the Teensy - is that the idea?



05-16-2018, 02:58 AM
Thats what I heard, I'm gathering you wifi to the RPI to basically remote upload the file to it's file server, then use the teensy command line tool on RPI to upload the HEX over USB

12-13-2018, 11:26 PM
Thanks, this is just what I was thinking of doing. If there was a compiler for the RPI then maybe one could just SSH in to it and do all coding work there? Work, compile, transfer sketch.

I've got a light wall (896 RGBW LEDS) and am outgrowing my Mega 2560 - but have really loved being able to remote upload since the main board is not easy to reach. The Bluetooth reset trick has worked for the Mega, but I need more than 16Mhz clock and 8KB RAM! So I'm hopeful the RPI solution will work with at least less steps than manual approach would require.