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

Status
Not open for further replies.
D

dozy

Member
Hi Everyone,

Does anyone know if Pin33(PTA4) on Teensy 3.1 is somehow special?
If it is tied low (even through a friendly resistor) teensy will not boot when applying power, nor will it reboot when the Prog button is pressed. After one of those two events has taken place, the 3.1 becomes unresponsive until power is completly disconnected, then the connection to PTA4 is removed, and power is connected again.

The Teensy 3.1 schematic shows that PTA4 is not connected to anything external to the MCU, so I'm assuming there is something special in the MCU itself. Maybe angry squirrels???

I have two Teensy 3.1s - one of them was untouched before testing these scenario - and they are both behaving the same way.

If this pin is special, how do I disable it's special-ness and use it as a normal I/O pin?

Thanks for you help,
Dozy
 
Last edited:
I have been trying to understand what pin D33 does and what it can be used for on the Teensy 3.x boards. And I think there might be some slightly incorrect information floating around in the forum on it. Not what Paul has said (because Paul REALLY knows his boards). But I think maybe a slight issue with @potatotron's statement. I was just hoping to maybe get clarification.

What I think the situation is is that pin Teensy D33 is MCU pin PTA4. At chip reset that pin defaults to being an NMI interrupt pin AND the EZP_CS signal. These are both active low and there is an internal pullup enabled in the MCU. So, by default (nothing connected to D33) then at reset there will be no NMI signal but, more importantly, EZP_CS will be low and the EZPORT mode will be enabled (NOT disabled). And I believe the MIN54 contains a loader program that uses the EZPORT mode to download programs to the Teensy MCU. So, if someone grounds the D33 pin at reset the MCU starts the JTAG controller instead of the EZPORT controller and the PTA0-3 signals connected to the MIN54 can't be used by the MIN54 to do EZPORT programming.

I've seen another thread where a user was going to add muxes to his custom board to connect the PTA0-3 signals to the MIN54 or a JTAG connector and then leave D33/PTA4 floating for MIN54 and ground that signal to use the JTAG connector. I think that sounds right to me. Anyone agree? Paul?
 
Yes and no.

Yes, pin 33 is defaulting to NMI. In a future version of the bootloader, I'm going to change the default. Until then, pin 33 really isn't very useful as an input pin (for any signal the might be low before you can reconfigure the pin).

No, the Mini54 does not use ezport. Pin 33 (PTA4) isn't even connected between the Mini54 & MK20 on the schematic.
 
Could I use this pin as an input interrupt when configured as an interrupt pin in a Teensyduino sketch for managing interrupts from sensors?
 
Yes, with some important constraints. The signal connected to the pin must be prevented from producing low-going edges until the pin is reconfigured. "Reconfiguration" in this case would be to set its "alt function" to zero, making it a normal GPIO and therefore disabling it NMI functionality.

If your hardware and firmware can meet that important constraint, then it's possible to use the signal as a normal interrupting GPIO input.

Paul's suggestion is a very very good idea, though. Using pin 33 as an output and allocating a different pin to the purpose of signalling an interrupt to the sketch firmware would make the developer's life far easier, eliminating the possibility of a minor configuration bug causing device lockup.
 
I'm working on a fix for the pin 33 issue, and the fix is turning out to be quite difficult. I will get this fixed, but it's going to take some time. I'm going to an event tomorrow through Sunday (Toorcamp), so I won't be able to work on this again until next week. A bootloader update to fix this and allow setting the lock bit is my top priority, even before SPI transactions, so I will be working on this when I'm back Monday.

The NMI pin can also crash the bootloader if pin 33 goes low while it's running. Worse yet, if the pin is low while the Mini54 is resetting the MK20 chip, the NMI can cause the MK20 to start up in NMI exception mode, which interferes with the bootloader using USB. The FOPT byte can completely disable NMI, but even that isn't a full solution for the bootloader, because if the chip needs to be fully erased to recover from a locked condition, there's still a window of time where the chip is responsive to NMI before that bit can be programmed again. It's not possible to program that bit while holding the system in reset, because the crossbar switch listens to system reset, so the Mini54 can only access the MDM and a couple core registers via the private peripheral bus only inside the ARM core, but everything requiring the crossbar switch is off limits while reset is asserted. The whole situation is further complicated by the ARM chip's fault mode, and hard lockup mode, both of which come into play the moment reset is released. I have several more ideas, but this is turning out to be a very tough problem. In hindsight, I probably should have ended at pin 32 and not brought out that signal!

For now, it's best to use pin 33 only as an output. That pin has a weak pullup, so it will default to high if whatever you're driving doesn't pull the pin down. Or if you can avoid using pin 33 at all, that's probably the simplest thing.

Eventually, that FOPT will will be default to disable NMI, and I'm going to harden the bootloader to handle all these complicated cases, so it will always manage to reprogram the chip, even if pin 33 is shorted to ground.
 
"Reconfiguration" in this case would be to set its "alt function" to zero, making it a normal GPIO and therefore disabling it NMI functionality.
Click to expand...

I have already run into this problem when trying to use this pin as an INPUT interrupt after reset and the Teensy 3.1 is running the program. Connecting pin 33 to the sensor interrupt causes the program to freeze. So how can I set the pin's alt function to zero?

I think Paul is working on changing the default behavior of this pin in the bootloader. But is there a possible 'software' workaround?

Edit: Just missed Paul's message before this post.
 
onehorse said:
So how can I set the pin's alt function to zero?
Click to expand...

You can use pinMode, or write directly to the config register.

Code: 
  pinMode(33, INPUT);  // disables NMI

  CORE_PIN33_CONFIG = 0;  // completely disables the pin

However, neither of these will be effective if the pin has ever been low before they run.
 
I'll check, but I am pretty sure I set pinMode(33, INPUT);, yet the program froze while it was running when I jumpered the sensor board connector to the pin 33 pad. Not urgent since the sensor is running without it, but I'm glad this issue has your attention. Wish I could help.
 
Just curious about this bootloader update - will this be something that can be updated via the Teensy Loader program, or will it require new boards? I ask because I know the bootloader is on a secondary chip, but I'm not sure if Teensy Loader has any access to modifying that chip's code.
 
I checked my code and I did NOT have pin 33 set as INPUT. I had the interrupt input set to the SDO address pin, which was set HIGH in the code, so I was always reading an accelrometer "data ready' condition. I verified that after correcting the error, setting pinMode(33, INPUT), resetting the Teensy 3.1 and running the program, I could use a jumper to connect the interrupt to pin 33 and would start properly getting accelerometer data interrupts output to the Teensy through pin 33. I know this because when I removed the jumper, the accelerometer data would remain constant, and only begin to change again when the jumper was in place.

Now my question is, dare I solder the interrupt pin to pin 33 and hope I can get far enough in the program to set pin 33 to input mode after reset, or should I wait for Paul's fix to the bootloader? I'm in no hurry so I will assume door number two is the correct answer.
 
onehorse said:
... or should I wait for Paul's fix to the bootloader? I'm in no hurry ...
Click to expand...

I will be working on it again starting today or tomorrow... just as soon as I get caught up to tons of messages that arrived while I was away.

My hope is to have a 1.20-rc2 version later this week, with the bootloader fix.
 
Is the fix available yet? I'm having an issue where the device I'm using causes pin 33 to go low on power up, causing the teensy to stop working.
If I connect the device after power up, everything works fine (provided I set pin 33 to output), but this is clearly not happening by default.

Thanks.
 
Not much can be done if you choose to use pin 33 until Paul provides a work around in firmware. But maybe you can pull up pin 33 to 3V3 with a 10 K resistor so it at least boots reliably. Any subsequent LOW will register properly.
 
Sorry if this is an obvious question, but is there any way you can move your pin assignments around so 33 is unused or an output?
 
Thanks guys. The pullup was just what I was thinking, just a bit ugly to solder up a pullup on a pcb. Will try soon.

Moving pin assignments around will be difficult. There is only one pin left unused, that is pin 26. Perhaps for the next revision of the pcb.
 
I'm interfacing with the ili9341 with parallel, and the 10k pullup doesn't seem to work. It's wired correctly, but whenever the lcd is powered on, the voltage still drops to around 10mV. Adding anothe 680 ohm resistor in parallel with the 10k, pulls it up to around 0.500V.
 
First, please let me apologize. This has been a known issue for some time, but a true fix has been repeatedly delayed. Lots of great stuff happened since, but this problem has persisted. I really need to get on this.

In the meantime, a quick fix that might let you output a signal to that LCD could involve a schottky diode and resistor. If you connect the cathode (side with the stripe) to pin 33, and the anode to the signal input on your LCD, and also a pullup resistor on the LCD pin to 3.3V, it should prevent zero volts at the LCD from driving pin 33 low. The downside, other than the hassle of adding 2 parts, is you'll get a logic low at the LCD of about 0.3 to 0.4V, or about 0.7V if using a regular diode. But maybe that can at least get things working now, until a real fix comes?
 
@Paul I run in this problem yesterday. I need half a day today to find the problem.
Please, you must communicate this problem on the Teensy 3.1 Page.

I don't like to find out about problems in this way. Better to publish, "Guys, don't use this Pins ..."

Could save lots of trouble. And time. And money.

Regards,
Andre
 
Thanks Paul. I may try that, though I'll probably end up doing some rerouting to pin 26 and removing the header of pin 33 altogether, using some messy external wiring.

As a side note. I agree with ^Andre. It's probably best if this was stuck on the teensy pinout or something, or at least a warning somewhere on the page. We all understand that you are extremely busy, and this issue probably isn't in the highest of your priorities. However, sticking a warning somewhere would be the most appreciated ;), especially for those that spend a long debugging their circuit only to discover it's an issue with pin 33!

Thanks.
 
Status
Not open for further replies.
Back
Top