Does program pin work on teensy 3.2?

Status
Not open for further replies.
A

astroyam

Well-known member
Hi,
I'm trying to get the Teensy 3.2 to re-program by setting the Program pin to high from a digital output of Pin 2. I have the TeensyLoader program running in Windows 7 PC.
I've tested the attached code on Teensy 3.1 and Teensy LC, and it works correctly, meaning the Teensy gets reprogrammed and then keeps running after I type a char into the serial monitor. By keeps running I mean the LED blinks and the Teensy sends the expected output to the serial monitor.
I've tested it on 2 different Teensy 3.2s and it doesn't work, one of which was fresh out of the package. It makes the first USB sound of being disconnected, but then doesn't get reprogrammed, and the LED stops blinking.

Wiring: I have soldered a wire straight from Pin 2 to the Program pin. No other wires are connected.
Thanks for any info!
 

Attachments

  • ProgramPin.ino
    550 bytes · Views: 173
This is the 3.1 schematic:
schematic3.gif
As you can see when the button is pressed Vcc is applied to Prog.
This means Prog is active high

This is the 3.2 schematic:
schematic32.gif
As you can see when the button is pressed Prog is grounded
This means Prog needs to be grounded in order to enable programming mode
 
Xenoamor said:
This is the 3.1 schematic:
View attachment 6249
As you can see when the button is pressed Vcc is applied to Prog.
This means Prog is active high

This is the 3.2 schematic:
View attachment 6248
As you can see when the button is pressed Prog is grounded
This means Prog needs to be grounded in order to enable programming mode
Click to expand...

Thanks Xenoamor

In my code, I am setting the Pin 2 to Low when I try to Program the 3.2. So that is inline with your second statement.
Looking at the schematic for 3.0/3.1, though, it looks like the button connects Prog to Gnd when closed. So programming the unit requires setting the program pin to low, and this I verified in tests on a 3.1.

Also, on a 3.2, I do get it to reprogram if I take a wire and touch it to Prog and Gnd at the same time. So that shows that Prog needs to be grounded to reprogram the 3.2. The problem I'm seeing is that the Pin 2 digital output doesn't seem to act like a ground when it is low. Whereas, with the 3.1 and 3.0 it does.
 
@astroyam: It grounded when I ran your code and stopped blinking. Assume you wired the 4th pin down - pin 2 properly of course to PGM?

Also in setup - it was indicated to me to write() the desired value on the OUTPUT pin before setting it to OUTPUT.
 
defragster said:
Also in setup - it was indicated to me to write() the desired value on the OUTPUT pin before setting it to OUTPUT.
Click to expand...

This is wrong and does not work for Teensy.
Try this:
Code: 
const int ledPin = 13;
void setup() {
  digitalWrite(ledPin, HIGH);   // set the LED on  
  pinMode(ledPin, OUTPUT);
}
void loop() {}

Then swap the two lines.
 
defragster said:
@astroyam: It grounded when I ran your code and stopped blinking. Assume you wired the 4th pin down - pin 2 properly of course to PGM?

Also in setup - it was indicated to me to write() the desired value on the OUTPUT pin before setting it to OUTPUT.
Click to expand...

Thanks Defragster,
When you tested it, did the LED start blinking again after you enter a char in the serial monitor, and did you see the TeensyLoader say 'Reboot OK'? If no to either of these, then the reprogram didn't work.... (Which is what happens on mine. )
I do have the 4th soldered, thx.
 
FrankB: You seem to be right - of course - I was corrected once and took it as true without testing that setting first was correct as it made sense, but I see it not working as expected.

astroyam: I have TYQT as my loader right now so the handoff to TeensyLoader isn't there to complete the test - I just saw it immediately go into program mode as expected.
 
It makes sense that you can't write an input - but it also makes sense to write the value you want when the pin goes to output before it would output a value you wouldn't want - or does it start up in some tri-state mode?
 
As far as i know, it (Teensy 3) starts in a "Hi-Z" high-impendance mode. On AVR, it is "Input", if i remember correctly.
I think Paul can say more.
 
Last edited:
Yes, Frank is correct. On Teensy 3.x and LC, the pins default to a disabled state. Pretty much all modern microcontrollers are doing this now, to enable low power designs.

The problems with digital input mode is both the N and P channel transistors inside the chip can partially turn on if the pin is at a voltage near the digital switching threshold. That's never an issue if you connect a digital logic circuit that always drives the pin high or low. But if you have an analog signal, or if the pin is unconnected and randomly "floats" to such a voltage, the transistors inside the chip can consume a pretty substantial amount of power. It's not huge, but it adds up if you're trying for a really low power design, especially with lots of pins.

On AVR, Atmel added pin disable registers for the pins with analog inputs. But they had to keep backwards compatibility, so the pins default to digital inputs until you disable them.

Nearly all modern microcontrollers now default to disabled pins. You have to enable the digital input. Until you do, the input buffer is shut off, so random or intentional analog voltage can't cause it to draw extra power.

In creating Teensyduino, I debated for quite some time about whether to turn on all the pins to digital input mode. I went to a lot of other extreme measures for AVR compatibility, and I seriously considered doing this too. Ultimately, I decided to keep the new behavior. It's just too valuable for people trying to create low power projects. It's also the way of the future. Well, actually the present. Pretty much all microcontrollers do this now. AVR is still very widely used, but it's on its way to becoming a "legacy" platform.
 
Hi Paul, do you have any insight into the original post above? The re-programming works with a teensy 3.1, but not with 2 of my teensy 3.2s. Here's the code.
 

Attachments

  • ProgramPinForum.ino
    528 bytes · Views: 138
On Teensy 3.2, an anti-glitch feature was added to the Program pin. On Teensy 3.0 and 3.1, even an extremely narrow low pulse could trigger programming code. Teensy 3.2 ignores very short pulses, which is intended to help prevent unintentional entry to programming mode for people who connect external pushbuttons or circuity which might pick up some noise.

Do you have a scope or logic analyzer? Maybe measure the pulse you're applying to the Program pin?
 
PaulStoffregen said:
On Teensy 3.2, an anti-glitch feature was added to the Program pin. On Teensy 3.0 and 3.1, even an extremely narrow low pulse could trigger programming code. Teensy 3.2 ignores very short pulses, which is intended to help prevent unintentional entry to programming mode for people who connect external pushbuttons or circuity which might pick up some noise.

Do you have a scope or logic analyzer? Maybe measure the pulse you're applying to the Program pin?
Click to expand...

Yes, I did look at it with a scope, and sure enough the pulse is very short. But, code wise, I don't send a pulse, I just set the digital output from pin 2 to low (and don't pull it back up high), which I connect via a wire to the Program Pin.
So, as far as I can tell, the only reason Pin 2 is going back up is that the reset is triggered. Is it possible that a short pulse causes a reset with out reporgram, and a longer pulse does reset and reprogram?

So, I can't elongate the pulse because I lose control of the processor as soon as I set Pin 2 low. Is there a way around that? Other than creating a delay analog circuit between my pin 2 and Program pin?
 
astroyam said:
But, code wise, I don't send a pulse, I just set the digital output from pin 2 to low (and don't pull it back up high), which I connect via a wire to the Program Pin.
Click to expand...

If you're doing this from the *same* Teensy that's being controlled by that Program pin, well, bad things can happen. You should only pulse Program from a different Teensy!

The correct way to initiate programming mode from your Teensy is calling the _reboot_Teensyduino_() function.
 
Ach, I poked around for something like that but couldn't find it!
Thanks, works great, much easier than wires.
 
I am observing a curious behavior on several Teensy 3.2s that I got from OSH( Listed as a Official distributor on PJRC web page). This does not happen on Teensy 3.1 I got from PJRC.

Observation:
If I measure the voltage using a DMM from PROG pin to GND when "blink" example is programmed:

PJRC Teensy 3.1: No issue.
OSH Teensy 3.2: The Teensy goes into "prog" mode, and stops the blink -> I suspect this is the mode because the device manager on my windows 7 laptop no longer sees a COM port. Only way I can restart this Teensy is to unplug from USB port and re-plug it back in.
This is very consistent behavior between the two versions.

I did notice that the schematic and part attached to the PROG pin is different between the two versions.

However I am not sure if it is my DMM or it is the boards. Anyone else notice this behavior?
Any insight as to why this is happening is appreciated
 
Search tyqt
Install it and it will show you the state of the teensy. It seems your dmm is grounding the pin into program mode. This seems like normal behavior.
Tyqt can do a software reset without unplugging.
 
@defragster,
OK thank you. I realize that the DMM is grounding the PROG pin, but should a DMM alter the state of the pin being measured?

If that were true, any other reading on the other pins should also change. However that is not happening. Only the PROG pin.

Not sure if DMM grounding the PROG pin is because there is no pullup on the PROG pin for T3.2 ?
Should there be a Pullup? I notice in the schematic there is none. Per data sheets of MKL02Z32VFG4 the internal pullups are between 20K to 50K ohms.. a bit too weak. I suspect the DMM simply discharges
the PROG pin. Perhaps if others tried the simple experiment : load Blink then measure PROG pin with a DMM that may help nail the issue.

Edit: I just noticed that the T 3.1 also does not have a pullup on the PROG pin, and after several attempts I was able to put the T 3.1 into a prog mode as well with my DMM. The MINI54TAN seems to have a weaker internal pullup. But T 3.1 seems to be harder to put into "prog" mode with my DMM. So I guess I still do not fully understand what is happening..
 
Last edited:
If TYQT installed - touch the DMM and hold it - then reset with TYQT. Does it work then to give a valid reading?

There is a balance on timing and voltage that works without external influence.

Not an EE: I was working on an ESP8266 system board recently and touching the free 2" wire end on the RESET pin would cause it to reset. Their is a transfer of energy on the touch. On another I wired the ENABLE pin to the Teensy that starts in a High impedance state - as soon as I enabled it as OUTPUT - and before OUTPUT could be written HIGH it was dipping the line and affecting the ESP8266 [odd effect baud went from 115k to 74k - still running]. I found that putting a small capacitor on the pin to hold some spare electrons was enough to make up the surge that went across the length of the pin. Your DMM and long leads certainly have more place to take the charge than the 1/8'th inch of wire and internal pathways of the Teensy.

Since I handle them so much - I've made a point of running my fingers over the Teensy and it never caused any adverse reaction - can you take a dry finger and cause it to go into program mode? Even on soldered pin tips of a T_3.1 and T_3.2 I can't get this to happen touching PGM & GND on the end.

BTW: my T_3.2 is a purple OSH unit. I just put my CENTECH (Harbor Freight) DVM on my OSH PGM pin running with no problem and measured 3.3V on the still running unit.
 
Last edited:
@defragster,
Yup, Even with TYQT installed same issue with T_3.2:
Here is what I did:
1. Load Blink on both T3.1 and T3.2.
2. Load TYQT, observe if I can reset each of the T3.{1,2} -- OK. (Done separately on the same USB cable)
3. Measure PROG with DMM:
4. T3.1 Stable, no issue
5. T3.2 -> Goes into PROG mode, COM port vanishes from device manager in Win 7, Cannot reset with TYQT.

Also did what you suggested : touch the pins with a dry finger -- this did not trigger any "PROG" mode.

Any other suggestions?
Thanks for your feedback, much appreciated
 
Status
Not open for further replies.
Back
Top