[Question] Teensy 3.1 - programming over Bluetooth connected to pins 7 & 8

Status
Not open for further replies.
rootScript

rootScript

Active member
Hello,
I am using a Teensy 3.1, and have connected the RX & TX pins on a Adafruit Bluefruit EZ-Link (Bluetooth module) to Teensy pins 8(TX3) & 7(RX3). DSR & DTR on the EZ-Link are not connected to anything.
In the Arduino 1.0.5 IDE, I have selected the Serial Port: /dev/tty.AdafruitEZ-Link046f-SPP, and the USB Type: Serial.
I want to upload a sketch to the Teensy, but the IDE returns:
Please press the RESET BUTTON on your Teensy to upload your sketch. Auto-reboot only works if the Teensy is running a previous sketch.

Having to press the button kind of defeats the purpose of programming the Teensy over bluetooth.
[Question:] How do I upload a sketch via bluetooth without pressing the button?
I gave tried this on an old Arduino Duemilanove (with EZ-Links's DTR pins connected Arduino's RESET pin, and everything works as I expected)

This is my 1st post here (please be gentle :))
Carlos

Link to Adafruits Bluefruit EZ-Link documentation
Hardware & Software setup: iMac13,2 Running OSX 10.8.5(12F45) - Arduino 1.0.5 - Teensyduino 1.18
Link to support question in the Adafruit forum is here
 
Last edited:
Short answer: (without a lot of work) you can download to the Teensy 3 only using the USB connection to the Teensy. That uses a special protocol, not a serial port emulation.

You can write a program/sketch that uses the serial port bluetooth to communicate, but downloading your program requires use of the USB port and the Teensy protocol that does not use a USB serial type device.
 
Hello Steve,
So as I understand it, you are saying that it is not possible to upload a sketch to the Teensy via bluetooth, as the "Teensy Protocol" in the Teensy 'Firmware' is only setup to be programmed via a USB serial connection.

I was hoping that I may be able to send some 'special signal' from the Bluefruit EZ-Link's DTR pin to the very tiny reset pin on the back of the Teensy, in order to put the Teensy into 'Programming mode'.

Is it likely that anyone has been working on a 'Bluetooth serial protocol', that could be 'flashed' to the Teensy firmware in order to use Teensy hardware serial pins 8(TX3) & 7(RX3) for this purpose?
 
Last edited:
That's correct. The "bootloader" in the Teensy uses a "helper" chip which contains code for downloading the flash of the ARM K20 CPU. The ARM CPU itself has no bootloader resident in the flash.

I haven't read of anyone working on a stack for the Bluetooth Serial Profile. When I've seen this done, people purchase a bluetooth module that has that stack aboard. Then there's a UART interface from the radio module to something - a microprocessor's UART or whatever. This gives your app communications via Bluetooth to a like-kind device on the other end of the wireless link, also with a Bluetooth serial protocol.

More popular, for "wireless serial UART links", is the Digi XBee Series 1.

But on the Teensy, you'll have to use its USB port for installing new firmware on the Teensy, assuming you don't want to do a lot of complex work.
 
Note, the Bluefruit can only be used on a select subset of Arduino compatible boards. Quoting from the adafruit page:
This techique can be used for Arduino Uno, Duemilanove, Mega and any other ATmega328/168/1280/2560 based Arduinos that use a USB->Serial converter. It won't work with "USB" Arduinos such as the Leonardo/Micro/Flora since they need a direct USB connection

The Teensy is similar in that it doesn't have the USB->Serial converter. Instead it does the USB processing in the hardware/firmware, and you have to use Serial1 to write to the serial line, and Serial to write to the USB connection.
 
So far I have tried connecting the DTR pin from the Bluefruit EZ-Link to the RESET solder pad on the back of the Teensy, hoping that it does the same thing as pressing the button on the Teensy, but no go. Does the reset pin on the back of the Teensy require a special signal in order to put the Teensy into programming mode? Maybe this RESET pin does work, but as you guys have stated it needs to be programmed directly via USB.

@MichaelMeissner
It won't work with "USB" Arduinos such as the Leonardo/Micro/Flora since they need a direct USB connection
The Teensy is similar in that it doesn't have the USB->Serial converter. Instead it does the USB processing in the hardware/firmware
Click to expand...
Does that mean that the Teensy 3.1 has a dedicated chip to do it's programming? So can I bypass it with an FTDI or CP2102 type programmer?

@stevech you said that:
on the Teensy, you'll have to use its USB port for installing new firmware on the Teensy, assuming you don't want to do a lot of complex work.
Click to expand...

This has been at the back of my mind for a while, and I can't seem to let it drop.
The Teensy 'Firmware' is only setup to be programmed via a USB serial connection; so how much "complex work" would be needed to be able to program it remotely via bluetooth?

Are you talking about reprogramming the Teensy down to bare metal, or are you talking about a "Fake" USB serial connection, or something else?

I'm still interested in finding a solution, even if it is a bit convoluted.:)
 
An alternative instead of uploading a full configuration hex is to upload a configuration file or script over the air, leaving the main program updates for times when you can plug in a USB cable. Your hex file would have an interpreter in it for whatever configuration format or scripting language you choose.

Elsewhere on the forum you'll find references to Python, Basic, and Txtzyme. My code linked below has a command parser for a serial console. The T3 doesn't know whether the serial commands are from the keyboard or prerecorded.
 
Last edited:
Any Luck?

Has anyone had any luck solving this issue? aka written a bootloader for teensy 3.1 that supports uploading new sketches using bluetooth. I'm using a teensy 3.1 with the HC-06 bluetooth module.
 
I know of two that have a bootloader for Teensy 3's. The concept is to not let the Mini-54 boot run and erase flash. Instead, put the bootloader + app as one program into the T3 as a normal program. At reset, this code runs and does one of a few scenarios to download form some medium (flash, serial, etc.) and rewrite, likely by running the code's boot functions in RAM. There are 2+ scenarios. uTasker's Mark - check his posts here on this topic. And FrankB.
 
Hi, I know this thread has been kicking around for a while, but I firmly believe relevant technical threads should never die.
Anyhow, I just picked up a Teensy 3.1. I needed an MCU with more memory and flash for a low volume product I'm building, and I liked the fact that there's an on chip RTC. Unfortunately, it seems like it's just not going to make the cut with no capability of simple field firmware upgrades with the Freescale chip with the separate Mini54 bootloader chip. The biggest problem is the monopoly that usb.org has created and their licensing restrictions. It basically kills everything. With the ATMega chips, I can easily upgrade my programs via Bluetooth SPP, getting around the USB obstacle. I'm not about to spend a $5000 for a VID or a year of my life coming working on or a with a half baked alternate solution so that the code on the Freescale chip can be swapped out via serial / use uTasker's code. I wish they had gone a different route when they designed this and wrote the bootloader code to be able to use the Mini54's onboard serial UART:(
 
This is not about USB.org (a lot can be said about them but thats another issue).

ATMega chips (Arduino) can be programmed over SPI, a simple serial protocol, and its well known how to hack this (bitbang) from a serial usb chip like the FTDI chips on Arduino UNO.

Thee Teensy 3.1 uses a very different protokol, the HalfKay lodader, that is loaded into the Teensy chip by the Mini-54, and it communicates over USB. This is not something that is simply reproduced by a bitbanged serial USB chip (might be possible, but HARD).
 
Teensy 3's bootloader protects PJRC's intellectual property and simplifies desktop development for most users.
A growing number of users want remote reprogramming. Using the T3 as is, perhaps the easiest way is to add an SD card to receive over the air/wire code update (files). Then invoke a bootloader built into the user's app, lying dormant until needed. That reads the SD card and writes flash sectors other than the sector in which the boot is always positioned. I and others have done this (though my work wasn't for a Freescale MCU). Doing the latter requires a special linker script file. It can be done. And has been. But Teensy 3 being arduino-centric, just isn't well suited for industrial apps where unattended remote reprogramming is essential. A custom board using the same MCU as T3, but without the Mini54 scheme for reprogramming, has been done by several folks.

Bluetooth for remote reprogramming... I suppose that use case is for no-touch reprogramming. Else BT's short range makes is a bad choice.

In the ARM MCU board cottage industry, the Particle.io Photon board is good at this - it can meet some semi-professional remotely reprogrammed needs.
 
Last edited:
I programmed my ATMega32U4's through the SPI interface when I started running out of space and needed to consume the bootloader's space. For a product that's not going to be used by engineers, SPI isn't feasible. A lot of people need BT for small, low power battery operated devices. I ended up modifying a bootloader for an Arduino 32U4 chip to be even easier to program using BT with an app that I wrote, so it was almost idiot proof. The variations of bootloader code that's out there for ATMega's is pretty straight forward after you decipher the meaning of all the objects, and adding your own comments. I also like the robustness of the Arduino bootloader design. So, I guess I'm stuck with the ATMega644p and 1284p for now.
I like the SD card idea. I will have to look at that. I've worked with lots of devices that look for a particular file name on an SD card, and if it exists, replaces the existing program with the one on the SD card. I wonder how much time had to be put into that?
 
I did it for an NXP ARM7 and then for a Mega328 and Mega1284.
And one for the ARM7 that did not use an SD.. it is an "in-place" reprogramming downloader. This had a small sized downloader and reprogrammer all in one flash sector. The downloader talks SPI to a Wiznet board. I wrote a passive mode (firewall friendly) FTP client that downloads intel .hex from a file server, parses the .hex, and writes flash on the fly as code comes down. The sector sizes on that ARM were rather small, like 8 or 16KB and the RAM was like 64KB. The downloader was written so that if the download failed, it left a flag in flash such that it would start anew next power-up/reset/watchdog timeout. This scheme worked well for 100 fielded units in several countries. We didn't want to fly people here and there for updates. The reason for this no-SD approach was that I had to retrofit remote reprogramming to these 100 units and it wasn't feasible to add an SD card. These things were installed in inaccessible places. The units checked with the file server periodically to see if there is a newer download available. So firmware updates were automated drops to the server.

So it's all challenging.
 
Last edited:
Wow that's quite a solution, and a really nice one, especially with the safety flag - very well done.
Right now I'm still writing a ton of application code, and keeping the bootloader and upgrade process for my final project in the my mind, trying to figure out how much I really want to customize the upgrade process. Did you happen to find any really helpful resources for working with the bootloader anywhere?
 
Status
Not open for further replies.
Back
Top