Teensy reset

Status
Not open for further replies.

paradajz

Active member
I don't really understand how the reset button on Teensy works (specifically - Teensy++ 2.0). It is my understanding that AVR resets into bootloader mode under these conditions (assuming BOOTRST fuse is disabled and HWBE enabled):

1) Power off
2) Hold HWB pin low
3) Power on
4) Enter bootloader mode

However, Teensy reboots into bootloader mode as soon as reset button is pressed. How is that possible?
 
Last edited:
I've not seen a T_2 - but on the T_3x and T_LC models the same behavior is because that is not a reset button - but a 'Program' button.

Pressing it, by design, takes the Teensy into Program mode - i.e. 'Enter bootloader mode'

HalfKay Bootloader Mode
Your Teensy contains 2 programs, the LED blink (user program) and the HalfKay bootloader. HalfKay, together with the Teensy Loader software, allows you to easily load new programs. Normally, the user program will run. To run HalfKay, press and release the tiny pushbutton.
 
Last edited:
Well, those models you mentioned can't really be compared since they have different methods of programming.
 
Not different from PJRC point of view as far as I can tell. Give it a look as noted . . . there was a linked page above to HalfKay Bootloader Mode that is specific to the Pre T_3 family

If you want to wire reset it looks to be exposed here on the bottom/end pins: http://www.pjrc.com/teensy/card4b.pdf

Sorry, but have you even read my post? I don't want to wire reset, I just want to know how it works on Teensy++ 2.0. Teensy 3.x has a way different method of uploading code since they use additional processor which handles bootloading. On AVR, that's done by manipulating BOOTRST/HWBE fuses and HWB pin in conjunction with resetting the microcontroller. Read my first post again.
 
I don't really understand how the reset button on Teensy works (specifically - Teensy++ 2.0). It is my understanding that AVR resets into bootloader mode under these conditions (assuming BOOTRST fuse is disabled and HWBE enabled):

1) Power off
2) Hold HWB pin low
3) Power on
4) Enter bootloader mode

However, Teensy reboots into bootloader mode as soon as reset button is pressed. How is that possible?

From the T2 description
Code:
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 this seems as you describe, apart that, for me, setting ALE (aka PE2 HWB) as an output signal means that T2 is running (has power)
You could simply try it (run blink, set ALE output high and press reset, then program shout restart and not going into Boot mode) or wait a couple of hours that Paul get up from sleep.
 
Sorry, but have you even read my post?

Apology accepted. Yikes - yes, I read your post (and did my best to answer) - apparently you have not read mine - nor the linked and related documents. There is no RESET button - it is a PROGRAM button (by default). It is part of the PJRC process to activate the bootloader on chip or off chip.

I don't want to wire reset
The word "IF" means - at your pleasure. So by all means don't wire up reset. But don't expect the program button to provide that functionality (without making some changes).
 
Last edited:
By definition that button resets the Teensy to Bootloader - aka Program - mode - just like the T_3 and later versions. As WMXZ points out from this page there is more to the story but it isn't normal or easy behavior . . . [This is an old post - and the 2++ seems to have an ALE pad ]

PaulStoffregen 12-19-2012, 04:09 PM

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.
 
Last edited:
PaulStoffregen said:
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.

So, basically, if that pin (HWB) wasn't tied to GND, but Vcc instead, then the reset button (RESET pin on AVR) would always start the application UNLESS the HWB pin is tied to GND before powering on the board. Is that correct?

Very confusing. That would actually mean the Teensy should boot to bootloader mode every time on startup since HWB is tied to GND. I can't wrap my head around this.
 
Last edited:
So, basically, if that pin (HWB) wasn't tied to GND, but Vcc instead, then the reset button (RESET pin on AVR) would always start the application UNLESS the HWB pin is tied to GND before powering on the board. Is that correct?

Very confusing. That would actually mean the Teensy should boot to bootloader mode every time on startup since HWB is tied to GND. I can't wrap my head around this.
Not really confusing, if you look at the schematic for the T2++ (not T2)
ALE let alone, the resistor will pull the HWB to ground. Power-on/reset defaults to bootloader reset.
ALE tight to at least 3V (external wire) then power-on/reset simply restart the program.
 
How is that so? Power on always runs the application code, even though HWB is tied to GND.
Maybe the AVR only checks the HWB pin to decide from which address to run (bootstrap code or application code), but runs fine afterwards?
Edit: I don't know about Power-on, but I try to understand what Paul wrote
Edit: maybe we should wait for Paul
 
Last edited:
I think I found answer in older AVRfreaks topic where Dean Camera responded:

Dean Camera said:
the HWB functionality only kicks in on the positive edge of the /RESET signal. Power ups doesn't do it, only reset pulses which many people find annoying.

Link to topic: http://www.avrfreaks.net/forum/need-at90usb162-reset-bootloader-help

So yeah. If HWBE is enabled and HWB pin pulled to GND, each reset will start bootloader, except for the power cycle, that is, powering up the micro.
 
That is exactly what I found as stated in the post above - ::

PaulStoffregen 12-19-2012, 04:09 PM

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
 
So, basically, if that pin (HWB) wasn't tied to GND, but Vcc instead, then the reset button (RESET pin on AVR) would always start the application UNLESS the HWB pin is tied to GND before powering on the board. Is that correct?

Very confusing. That would actually mean the Teensy should boot to bootloader mode every time on startup since HWB is tied to GND. I can't wrap my head around this.

No. The AVR chip handles power-on reset and a rising edge on the reset pin differently.

As Teensy is wired, power on reset always runs your program. Pressing the button or pulsing the reset pin (which is what the button press actually does) causes the bootloader to run.

The way Teensy works is documented here:

http://www.pjrc.com/teensy/first_use.html

If you want to hear it directly from Atmel, refer to the datasheet:

http://www.pjrc.com/teensy/atmega32u4.pdf

Refer to page 80 "HWB allows to execute the bootloader section after reset when tied to ground during external reset pulse" and section 27.5.3 on page 335.

From the unpleasant tone in several of your messages, I'm getting the impression you're unhappy about some part of this. I really don't know what to say, other than this is simply the way the hardware works. I've tried to document it on the website. At least a few times (quite a long time ago), the messages shown by the software have been improved to more clearly explain the button is for entering program mode. I just don't know what more I can do for you.
 
For advanced users the way the button works seems a little ambigious in the docs. So understanding the bootloader's ABI-level operation vs. POR vs. button-press would allow for understanding some parts of the other code. Here are some questions I am looking at now.

How do Power On Reset and bootloader jump to application start differ in terms of CPU register setup? POR register default values can be found in the datasheet. Is the bootloader warm reset (i.e. pre-C _start() ) described somewhere? For example does the bootloader clear RAM, or some regs, or not, etc. Some of this is CPU specific, some is bootloader implementation specific. Some of it like initializing RAM is maybe avr-gcc startup specific (C++ init). For example. Does it clear any Reset Flags etc (MCUSR), for example Power-on Reset Flag. Does the bootloader disable WDT upon entry, etc:
ATmega16U4/32U4 [DATASHEET] page 57 Atmel-7766J-USB-ATmega16U4/32U4-Datasheet_04/2016

Note: If the Watchdog is accidentally enabled, for example by a runaway pointer or brown-out condition, the device will be reset and the Watchdog Timer will stay enabled. If the code is not set up to handle the Watchdog, this might lead to an eternal loop of time-out resets. To avoid this situation, the application software should always clear the Watchdog System Reset Flag (WDRF) and the WDE control bit in the initialization routine, even if the Watchdog is not in use.


It seems there is a difference between warmstart and coldstart for example here.

Code:
$ grep -6 restart ../../code/cores-master/usb_midi/usb.c
					b4 = UEDATX;
                                        usb_ack_out();
                                        usb_send_in();
					if (b1 == 0xA9 && b2 == 0x45 && b3 == 0xC2 && b4 == 0x6B)
						_reboot_Teensyduino_();
					if (b1 == 0x8B && b2 == 0xC5 && b3 == 0x1D && b4 == 0x70)
						_restart_Teensyduino_();
				}
			}
                }
		if (bRequest == 0xC9 && bmRequestType == 0x40) {
			usb_send_in();
			usb_wait_in_ready();
			_restart_Teensyduino_();
		}
        }

where, the reboot function does this
asm volatile("jmp 0x7E00");

and the restart function does this
asm volatile("jmp 0");


The right choice of jump to target in a different application's shutdown/reinitalization routine is.. ?
 
Question: Is the "reset" pad on the Teensy 3.6 board an input or an output? I'd like to have a functioning reset button, separate from the bootloader button, at least while I'm debugging my app. If it's an input, how should it be used?
 
On Teensy 3.6, the reset signal (not Program, but Reset) is an open collector input & output. Like all open collector signals, never drive it high, only pull it low.

The bootloader is designed to recognize when an external system is pulling the Reset line low. Still, it's advisable to avoid doing this during programming, as there will be a brief delay before the bootloader can gracefully stop. If you absolutely must do this, at the very least keep the Reset pin low for at least 20 ms or more.
 
Status
Not open for further replies.
Back
Top