View Full Version : Teensy 2++ won't start user code after it gets reset input on power up

12-19-2012, 04:47 AM
Hi - now I would like to retitle this post "Options for starting remote Teensy 2++ in HalfKay or application mode" since that is perhaps more accurate, but here goes.

We have a Teensy 2++ installed on a custom board intended for an embedded application where USB and the reset button won't always be accessible. We provide 3v3 to Teensy. Our board also has a supervisor chip which holds everything in reset until the 3v3 supply reaches 3v0. This creates essentially the same situation as holding the reset button on Teensy until power is stable. In all of my mission-critical systems to date we have such a chip since internal reset logic of controllers usually isn't that precise and we don't want the controller trying to access I/O before power is really stable and at its proper voltage. Without this, many controllers will start up at a much lower voltage - well before the I/O devices are ready. That supervisor reset also puts all the I/O into a known safe state on power up, power down, and in case of brownout or brief power outages.

What we find is that Teensy won't boot up its user program. It seems to be stuck forever waiting for a USB response which will never come. If we disconnect Teensy from this supervisor/reset chip then it boots up and runs our code OK. We're getting by with this now but under harsher conditions I don't like the idea of not being able to hard reset Teensy to a known state (other than by removing power completely).

So I have tried to find a clear description of the reset input and the Teensy 2 bootloader and the best I could see is that reset puts Teensy into a mode where it expects to talk to the PC part of the loader and it will apparently wait forever. First question: is there any way around this, such as a timeout in the Teensy loader? Or can we send the USB port a signal that tells HalfKay to just start up the application already? We were planning to use the USB port for a data logging option on a connected PC, used by a lab tech. I looked on the web site for advice about this reset/bootloader issue but there doesn't seem to be a master documentation page with a list of topics (hint).

Second question: since our system will be in a tube underwater, with a data and power cable to the surface, it seems like we can't reliably load new code unless we also bring the Teensy reset signal to the surface since it is sometimes needed to put Teensy into the mode where it will look for the PC loader. I'm guessing there is no way around having access to a manual reset input to Teensy. But, and this is related to the first question, we can't use the Teensy reset signal to actually just reset Teensy: it will always hang waiting for communication with the PC part of the loader. Sending it a new hex file on every startup isn't a solution.

Maybe there is a page with all startup and reset options/tricks somewhere? I have vague memories of reading something about this when I didn't need the information but now I can't find that source again.


12-19-2012, 05:52 PM
Yeah, I'm replying to my own post...

Restating our situation: our application Teensy is in a tank of water with cables for power and USB data (control and logging) coming to the surface. When a lab tech is running the system we want Teensy to always run the application program and use the USB for control commands and to send back result data. When I show up in the lab and plug my notebook into the USB I want to be able to send the Teensy new code.

In order to allow in situ programming of our application Teensy, we can either
1) run the reset input out of the water tank over a few feet of cable, buffering if necessary, to get the Teensy HalfKay loader into a "wait for a loader event" state. This would also let us recover from hung application code such as a bad interrupt handler. Once we put it into this state the only way out is a power cycle or to send it a new hex file.
2) our supervisor chip drives the Teensy reset on every startup which puts HalfKay into the "wait forever for a loader event" on every power up. Now, how can we ever tell it to stop waiting for the loader event and just run the user application? There might be some USB command to do that but I have not discovered it. I'll try the cli loader and see what I might stumble onto.
3) Just now on the schematic page http://www.pjrc.com/teensy/schematic.html I found the remark "The ALE pad should only be used as an output signal. If this pin is driven high while the reset button is pressed and released, the board will not run the Halfkay bootloader." So if we can make our hardware intelligently control the ALE pin then we might be able to control whether on boot-up our application code or HalfKay runs. This would let us use our supervisor chip if we can figure out how to control ALE at reboot time. Has anyone implemented such an option?

Found this page about bootloading from a PC command line: http://www.pjrc.com/teensy/loader_cli.html but the foolproof version requires another Teensy to reset the main Teensy. I took a quick look at the code. Sorry if I am being a dolt but I'm a bit lost as to how this would work. There's no documentation describing exactly how rebooter works, specifically how the two Teensies are connected: the html page says to connect C7 from the Reboot Teensy to reset(L) input of the application Teensy. The application Teensy is connected by USB to a PC running teensy_loader_cli which is trying to send a hex file. The reboot Teensy expects a "reboot" USB message from a connected PC, but I don't get how the two Teensies know each others' state to coordinate this.

The HTML page for loader_cli says:
If you connect a second Teensy using the rebootor code, add the "-r" option and your code will always be programmed automatically without having to manually press the reset button!

In rebooter/usb.c there is a parsing of the incoming text "reboot" which then pulses all ports low for 25 usec. OK, so if we add that -r argument to the makefile line, that invokes the -r : but this is on the loader_cli which is sending the hex file to the application Teensy... looking at the teensy_loader_cli.c source it appears that the rebooter Teensy is on a separate USB port and is opened independently of the one being sent the hex file. Is that correct?

So as long as the rebooter Teensy always starts up and runs the reboot application, and it responds to the loader_cli connection, it will reboot the application Teensy while that same loader_cli application is working to send the hex file to the application Teensy. Is anyone using this dual-Teensy option and can report on its reliability? If we don't care about the automation of loading new code, does anyone have thoughts about the reliability of the dual-Teensy vs bring-out-reset-input vs use-ALE-to-control-startup-option?

Or if I am hopelessly confused please point me in the right direction.


12-20-2012, 12:09 AM
Teensy 2.0 has 2 different resets. The normal reset causes your program (at location zero) to run. The bootloader reset causes the bootloader (near the end of flash memory) to run.

Power on reset is always a normal reset.

A low-to-high transition on the reset pin, caused by either the pushbutton or an external signal, defaults to a bootloader reset. The voltage on the HWB pin determines if the reset pin causes a normal reset (HWB high) or bootloader reset (HWB low). On both Teensy 2.0 and Teensy++ 2.0, the HWB pin is connected through a 1K resistor to ground, causing the default reset pin behavior to reset to the bootloader.

If you want to control which type of reset the low-to-high transition on the physical reset pin causes, you'll need to control the HWB pin. On Teensy++ 2.0, it's the ALE pin which is easy to access. On Teensy 2.0, it's not brought out to a pad (there simply isn't any more room on the board), but if you're good with tiny soldering, you could connect a wire to the pin or to the 1K resistor.

You could also leave HWB low (the 1K resistor) and use another Teensy running the rebootor program to pulse the reset pin, and then a modified version of the command line loader to send the command to run the user program. In terms of reliability, that solution depends heavily on how reliable you USB host system might be. Teensy 2.0 is very reliable as-is, so building a complex system may or may not actually make an improvement.

Another possible approach you might use would be startup code on Teensy which uses analogRead() on a resistor divide of the power supply, and of course the internal reference, to tell when the voltage is at least 3.0 volts.

05-28-2015, 11:10 PM
The voltage on the HWB pin determines if the reset pin causes a normal reset (HWB high) or bootloader reset (HWB low). On both Teensy 2.0 and Teensy++ 2.0, the HWB pin is connected through a 1K resistor to ground, causing the default reset pin behavior to reset to the bootloader.

Well, i really can't seem to replicate this on a Teensy++ 2.0. It just keeps rebooting from the Halfkay bootloader.
I assume the correct execution order is ALE Pad HIGH, RESET Pin LOW, RESET Pin HIGH, where both are connected to different digital output pins and the RESET pin is given HIGH on the very first line in the setup function.

Did i forgot something? :confused: