Teensy 3.1 - Tying Pin#33 (pta4) low freezes teensy.

Status
Not open for further replies.
Yes this needs to be know.... I just spend 2 hours trying to figure out if I was pulling to much(using more then half the total pins) from the Teensy that it would fail to reboot after flashing....... Turns out its because im using pin 33 as in input.....

So glad im testing this with solder-less boards instead of dropping the $250 on the blank boards.
 
Is pin 25 somehow special also. I have button connected to it and when pressing the button, it causes delay on execution and this is very noticeable on fast 1 ms motor control loop, the motor looses control. It happens even when Pin 25 is not causing any action on code. The button on pin 25 work ok when the code is activated, but still causes delay on the motor control loop.
 
Thanks, I am still coding and must ensure everything, but I am pretty sure that when putting pin 25 low it causes delay or something, though it is not used in code other than defined pinMode (25, INPUT_PULLUP); //Button

Note: I have most pins in use, 2 motor controller, SPI, Serial1, I2C, but it is pulling pin 25 low that causes the motor controller to lose control. This is actually not a big problem as motors will not run after button is used (when the code is fully implemented, button has no affect yet to this). just wondering.
 
Thanks, my code is currently too complicated and requires also all the HW to work and I can not share it. I let you know if I find the reason and if not I will try to generate simple code demonstrating it.

It is strange even if I have nothing defined to pin 25, pulling it low causes the problem. I pull it directly to GND. Should I use some resistor? I suspect it could cause something to the PWM outputs on pin 22 and 23 or Pin 27 that is a input that is pulled low with 4.7k
 
After some investigation I am pretty sure this is some kind of electrical interference problem, not code related.
 
@HWGuy found the post: None-booting-custom-teensy-board

This applies to T_3.2 with the new chip:

PaulStoffregen said:
The new bootloader always disables the NMI feature in the flash config byte immediately after erasing the flash. Writing to flash only changes 1s into 0s, so there's no way to re-enable NMI by normal loading of programs. The new KL02/04 chip also has code to turn NMI off before running the bootloader, while the CPU core is still being held in reset. So the bootloader should be able to run in all cases, even if you've wired pin 33 low.
Click to expand...
 
Here's an interesting tidbit about my recent experiences with Pin 33...

I originally built my latest project to drive one of the Adafruit SSD1306 OLED's so I routed a digital I/O pin to one of my i2c headers for the needed reset line. I was running out of pins and didn't realize that pin 33 had issues so I used it. Everything actually worked perfectly with my T3.2, no issues at all.

However my client decided he wanted a larger (and cheaper) display so I switched to one of the SH1106 boards floating around on eBay (which does not need a reset pin).

Yesterday I decided to add one of the Polou Power Switches (I'm testing with the LV version of https://www.pololu.com/product/750) and since it needed an extra ground line - as well as a digital I/O pin for the shutdown function - I decided to reuse the pin 33 header (since it had ground right next to it).

I was amused to note that when I tried to power the Teensy on with the Pololu Power Switch (with it's shutdown pin connected to 33) it would turn on, then turn right back off. I moved the shutdown pin to another free pin and all was well.

Certainly not a fatal problem but something I figured I'd mention in case someone else was stupid enough to do the same thing.

Regards,

Brad.
 
AH, yes, pin 33 has a pullup resistor which defaults to enabled.

Teensy 3.2 fixes the problem where driving pin 33 low causes trouble with running programs and uploading new code, but it does not disable the pullup resistor. Pin 33 still will output a (weak) logic high during upload and at startup, until your code reconfigures the pin.
 
I just ran into this pin 33 issue on teensy 3.2.

pin 33 is connected to a ULN2003 input, so I am using the pin as output.
when teensy is powered up, it immediately shuts down. If I pull it out of the socket, it still won't run until I press the prog button on the teensy.
If I plug the teensy 3.2 back in the socket, but with pin 33 disconnected, the teensy program runs fine.

so it seems the ULN2003 input is affecting teensy pin 33.

My pin assignments are fixed and all pins on the teensy are used.
any way to work around this?

thanks.
 
ok, I connected a 1k resistor from pin 33 to 3.3v and that seems to fix the issue, even on teensy 3.1.
 
yeah I figured that, so in my final circuit, I used 10k. It works to run the program, but I am unable to upload a new program. I have to unplug the teensy to upload a new program. No wonder there is no permanent solution to this issue other than not to use pin 33.
 
have you tried increasing a series with the weak pullup? (like they do when programming thru ISP on arduino with something else on the SPI bus to prevent flashing conflicts), im sure they do it to arduinos uart0 as well pins 0 and 1 (if device attach cant program, but it can be dealt with some resistors
 
Last edited:
I used 1.5k pullup and program runs and I am able to upload programs without having to pull the teensy out of the socket.
There might be an optimal value, but I don't want to spend more time on this issue than I already have.
 
hmm, turns out the teensy I thought was 3.2 is actually a purple version 3.1. I thought all my purple teensies are 3.2. I guess not.
I'll get a couple 3.2 to try. The last 3.2 I was using started running hot and shuts down so it got damaged for unknown reason.
 
Status
Not open for further replies.
Back
Top