Teensy 3.1 Reset

Status
Not open for further replies.

jomac

Member
Is it me an am i missing something? I wanted to have a reset button external to my Teensy 3.1 Looking at the schematic here...

https://www.pjrc.com/teensy/schematic.html

Shows a reset connection going out to the edge of the board, but looking at the photo card that came with my Teensy, the reset pin is marked DAC/A14 next to the program connection.

Which is correct, and does the teensy have an external reset connection?

John
 
On 3.1, the reset signal was moved to a test pad on the bottom side.

Details are here.

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

Scroll to the end of the page for the stuff about the reset location.

With so many awesome features in such a small form factor, trade-offs are necessary. Having the DAC output easily accessible was considered to be worth the inconvenience of relocating the reset signal.
 
:'( I ended up circumventing the problem described here http://forum.pjrc.com/threads/23647-Powering-Teensy-3 by just pulling the reset pin LOW during start-up.

Now I have a eighteen teensy 3.1's sitting here and can't use them on my boards. I am a VERY sad camper right now:( and it's not even camping weather. I guess I should have read it more closely.

I'll need to make a new revision I suppose. Could you recommend a way to drop this onto a board and connect the underneath? I could just make a via there and then pour a ton of solder in from the bottom?
 
Last edited:
We had a small handful of problems with the Teensy 3.1 and the connections underneath, unfortunately, in our opinion the connections certainly are not suitable in the hobbyist environment where the same micro would/could be used over and over again, the pads arent up to anything other then a 1 time connect and then left alone. Neither were we happy with the thoughts of connecting pins to the pads and soldering the micro onto another board as this would severely restrict upgrades and or replacement.

We have 4 Teensys with pads that have pulled away, no matter how careful we were with them, and now 3 teensys which have died for no apparent reason during prolonged testing of prototypes.

To access the pads underneath we had to solder thin wires to them with a multiway plug on the other end, and to ensure that wires and pads didnt pull away during plugging and unplugging, we glued them in place with epoxy resin. Not a good solution no matter which way you look at the situation.

It is these and other issues which have made us question if we made the right choice with this little board, certainly in this small configuration its too delicate for prolonged 'playing' with.

Out of 25 we initially bought, 7 are either damaged or dead, not a good start..:(

John
 
http://www.emulation.com/catalog/pogo/

Intended for 'bed of nails' test gear you could use pogo pins on the pads underneath, not strictly easy but hardly impossible either. Use regular headers and sockets on the holes and they will hold the little PCB down onto pogo pins well enough if you engineer it right.

Similes have worked for me when I needed them to. Never personally tried it with Teensy before, all my experience with pogo pins has been for test fixtures and they are excellent.
 
Last edited:
Mill-max makes some mechanical interconnects - pins,sockets, etc. I've used their spring pin sockets - a few thousand. Work well for plug-in boards that use common headers inserted into spring sockets.
If I recall, the company has surface mount sockets too.

https://www.mill-max.com/
 
I was surprised when I figured this out as well. At first I thought the button on the board might act like a reset. Nope. Then I found this thread, and the schematics and board layout. There's no good way to expose the reset pin. Would have been better if the test point were on the top of the board, then it might have been possible to cut a trace and add a wire. Guess I'll try adding a P-channel fet and a switch and see how that works.

Greg
 
Digikey P/N FDN337NCT-ND

It passes the battery voltage from the input to the output when the gate is floating. If you connect the gate to the +V on the battery, it will turn off the output.

I have it up and running right now on a different board

And the switch I was going to use : SW1020CT-ND
 
This won't necessarily help, but here's a bit of history about how things ended up the way they are today.

The original design for Teensy 3.0 was going to use a 48 pin chip, basically the same physical size as the chip on Teensy 2.0. It had just enough I/O to fill up the 28 pins on the outside edges of the board, 24 signals and 4 power/ground pins.

I first heard about Freescale's 32 bit ARM chips in 2010 and got a some samples and one of their tower boards with the early (larger, too expensive) version of the part. Freescale was about 1 year behind their original schedule for releasing the smaller, lower cost version of chip (in physical packages that could fit on a Teensy board). Samples in 64 pin became available in Jan-Feb 2012. In late 2011 and early 2012, I contacted the Freescale rep and distributors several times, until _finally_ in April 2012 they at least had the part number set up. PJRC placed an order for thousands of chips. I called once a month, to confirm the order was on schedule.

The day before the chips were supposed to ship, Freescale rescheduled with another lengthy delay! I don't recall now if that was while we had the Kickstarter officially launched, or just about to start. It was looking like we'd have to wait another 2-3 months.

However, the 64 pin version was not being delayed. At first, it seemed impossible to fit the 64 pin version on the PCB. But after few days of PCB layout, I managed to just barely make it fit. The bigger chip had a dozen more I/O pins. It seemed like a terrible shame to not be able to bring them out to pins, like so many of the extra signals on Arduino Mega and Arduino Due that can't be used. Adding the pads on the bottom of the board made the PCB layout a LOT harder. At first it seemed impossible, since they block so much area for vias. But after about a week of PCB layout work, I managed to make it fit. All but 1 analog-only pin was at least accessible.

I had considered making the board larger and bringing all the pins to the edges. Perhaps Teensy 3.0 would have been just as successful in a 40 pin format like Teensy++ 2.0? There's always a lot of trade-off decisions in any design, and very strong feedback from a LOT of people involved the physical size., where Teensy 2.0 could fit into lots of projects where Teensy++ 2.0 was physically too big. Even 28 was a small increase over 24 on Teensy 2.0.

Among the many lessons learned from Teensy 2.0 involved the importance of following certain pinout conventions from Arduino Uno. Having at least 14 digital-only pins, Serial1 on pins 0 & 1, SPI on pins 10-13, the LED on 13, PWM on 3, 5, 6, and I2C on A4 & A5 makes so many existing examples "just work" when people follow their hard-coded (either code or documentation) pin specs.

The decision was kept at a 28 pin outside size (24 I/O, 4 power), with 5 power/reset pins on the non-USB edge.

The bottom-side pads were never meant to make Teensy 3.0 "pluggable" in a socket. In fact, they were originally never meant to be there at all. It was truly a last-minute decision to switch to the 64 pin chip, only because Freescale had delayed the smaller 48 pin chip that fit nicely. Basically, the idea is "at least provide some way to get to all those extra pins". Most other boards with high pin count chips, like Arduino Mega and Due, just leave the extra pins unconnected and you can't get to them.

By mid-2013, Teensy 3.0 was becoming pretty successful, with nearly all Arduino functionality working, most libraries ported, and OctoWS2811. But I heard quite a bit of feedback on the limitations of the chip. Even though no other Arduino compatible boards were offering anything close to 16K of RAM at $20 retail, RAM was becoming a huge limitation for a lot of projects. With the audio library planned, more RAM would be needed for effects like chorus and reverb, or projects using audio and many-LED display like OctoWS2811.

From the beginning Freescale has been much better to work with than Atmel ever was. As Arduino became a bigger deal in 2013, they seemed to take some interest. We had been buying the chip in respectable quantity, probably still peanuts for such a large corporation. When I first talked with them in 2010, nobody had heard of Arduino. By 2013, Arduino had become a household name and they were interested in PJRC's efforts to bring their chips to Arduino users.

Freescale gave us a good deal on upgrading to the bigger chip that's now on Teensy 3.1. It still was a pretty good jump in cost, but we agreed to buy more (a bit of a nerve-wracking financial risk for me & Robin....) and we increased the Teensy 3.1 price just a little to try to offset some of that jump. Teensy 3.1 isn't quite as profitable, margin-wise, for PJRC, but overall it seems to have been worth the risk. PJRC has always been first and foremost about projects and publishing free resources.

The new chip was pretty much pin compatible. The only difference was several pins got more functionality. But that 1 analog-only pin I didn't manage to route on Teensy 3.0, because there wasn't anywhere to put another pad (even on the bottom side) and because those 14 rectangular pads block any new vias, now had a DAC function.

True analog output is an awesome feature... far too awesome to leave unrouted to the outside world. Just imagine how upset people would have been with me if I'd taken the easy path of just putting the bigger chip on the same PCB and the silicon had a real DAC that could couldn't get to, at least not without being able to solder a wire to a 0.25 mm pin! I wanted to preserve 3.0 to 3.1 pinout compatibility as much as possible, but the DAC had to come to an outside pin.

I considered replacing A10 or A11. I considered taking away one of the A6-A9 pins. Digital 0-13 and analog A0-A5 are untouchable, since there's an huge universe of Arduino developed code requiring those pins. I thought about removing VBAT. Taking away the place to add a 32 kHz crystal would have made the Teensy 3.1 PCB redesign a LOT easier, since it's right near where that extra DAC pin is.

Ultimately, something had to give, and the reset pin got the axe. Something had to go to make room for DAC output and reset was felt to be the least bad choice.

Luckily, removing reset of the right-edge pad freed up just a little signal routing space on the PCB. I was able to shuffle things around and get that previously impossible-to-route A14 pin to the pad where reset had been, without having to chop any other features. It took a couple solid days of fiddling with lots of traces and vias by less than 1 mil increments, but it worked and passed design rule checks (the PCB is 6 mil spacing, 4 layers, and by far the hardest PCB layout I've ever done).

Moving reset to that little test pad also meant PJRC had to built a whole new bed-of-nails test fixture. There just wasn't any reasonable way to add another pogo pin to the old one. This delayed the Teensy 3.1 release, but in the end I think all this trouble was really worthwhile, to get true DAC output.

Of course, if you're wanting reset on an outside pin, or you want a pluggable Teensy3 with more than the output 24 I/O, this long-winded explanation probably doesn't help. There simply are a lot of trade-offs in making any product for such a wide range of people.

Later this year PJRC is planning to add more Teensy3 products. I can't give you specific details yet, but I can tell you they also involve a lot of these difficult design trade-offs. I really, truly do care about making the most awesome products possible. I am willing to go to pretty extreme design effort rather than taking the easiest path. But there's always difficult trade-off decisions to make, and keeping the boards physically small is always a goal at odds with expanding features.

I do get a LOT of input from a huge number of people with widely varying needs and desires. I try to take as much into account as I can. I often don't have time to reply to every message, but I do read them. If you have input on features, I'm always happy to hear it.
 
Last edited:
Paul,

Thanks for the explanation and history lesson. I'm sure none of these decisions are easy, especially with the desire to support new features yet remain backward compatible.

What do you suggest for those who wish the functionality of a reset input? Is yanking the power an acceptable solution? Or possibly some code tricks coupled with an input pin?

Greg
 
What do you suggest for those who wish the functionality of a reset input? Is yanking the power an acceptable solution? Or possibly some code tricks coupled with an input pin?

With access to only the outside 28 pins, power cycling would be the most reliable way to cause a full reset.

If you can solder a wire to the test pad on the bottom side, of course you get direct access to the actual reset pin. Some people mount the Teensy 3.1 upside down, so those pads are easily available.

All pins have interrupt capability, but interrupts can be disabled by software, so using an ordinary I/O is only effective for "normal" programs where interrupts don't remain disabled. You can initiate a reset by software (it's been discussed in other threads), so if you're ok with this approach, attachInterrupt() may be the simplest way.

Likewise, you could try to respond by some command delivered by USB, like a HID feature request which you could detect inside the USB interrupt. But this gets into thorny USB programming, and it also comes with the caveat of being ineffective if interrupts aren't enabled.

You could also try using the watchdog timer. If you're looking to improve reliability, where you want to automatically reset if things go wrong, that's exactly what the watchdog is meant to do. But as simple as the watchdog is, applying a watchdog timer properly, so the net result is a more reliable system, requires great care. It's easy to make mistakes, where the net result is the watchdog accidentally resets, causing the whole project to become less reliable than if you'd simply done nothing. Applying the watchdog well requires a very carefully designed system where you are absolutely certain on a regular basis that things are working, and only in that case do you clear the watchdog, and by design that case always happens more frequently that the watchdog's timeout.
 
The watchdog timer is, IMO, a better solution. During desktop development the reset button is convenient because when using a debugger with breakpoints, one has to disable the watchdog timer.
In all the embedded work I've done over many years, the watchdog timer is used for real products in the field because Murphy prevails. Just one missed interrupt from an attached device can hangup software that took this infamous assumption "My Boss Said This Can Never Happen!". I saw that phrase displayed on a screen years ago, coming from a production quality piece of software on a PC.

As I've learned to work with T3's (using VisualMicro as the IDE), I find that I extremely rarely have to power-cycle or push the reset button.

I have to give lots of kudos to Paul for a truly amazing design job on the PCB and the Arduino compatibility software efforts. The epitome of a "Jack of all trades", rare these days.

Paul mentioned upside down installation of pins. Here are some I'm working with, a mix of 3.0 and 3.1. These have a SiLabs 4431/4432 data RF transceiver (two different vendors' PCBs). Two have inverted pin/sockets. The inverted pins T3's are: one on the largest breadboard and one place diagonally bottom-center. One non-breadboard 3.0 has the radio piggy-backed, no breadboard. This is experimenting with star and mesh routed networking with $4 radios in 433MHz/GFSK.
 

Attachments

  • T3s w SiLabs 443x radios.jpg
    T3s w SiLabs 443x radios.jpg
    133.7 KB · Views: 552
Last edited:
During desktop development the reset button is convenient because when using a debugger with breakpoints, one has to disable the watchdog timer.

The watchdog timer in this chip is debug aware. Here's the relevant text from section 23.3.7 on page 469:

You can program the watchdog to disable in debug modes through DBG_EN in the
watchdog control register. This results in the watchdog timer pausing for the duration of
the mode. Register read/writes are still allowed, which means that operations like refresh,
unlock, and so on are allowed. Upon exit from the mode, the timer resumes its operation
from the point of pausing.

If you've been having trouble with it accidentally resetting, try setting that bit so it pauses while the chip enters debug mode.
 
This is a slightly old thread, but I'm sure that others are still visiting this through search engines, even if not the OP.

A very basic and easy fix is to move your loop{} code to be inside a while(1){} loop and then move your setup{} code to the beginning of loop{}. Then use digitalRead with pullup or pulldown on a switch and if(){GOTO:} or breaks to simulate a reset. But it sounds like the other more advanced solutions would work for more situations.

Found this soldering solution that allows Teensy 3.1 to be replaced:
http://rishifranklin.blogspot.com/2014/06/teensy-31-reset-pin.html

Regarding the P-FET, the part appears to be an N-FET which could also work to switch ground. Either way, a pullup/pulldown would be better than a floating gate I believe.

Regarding frustration during testing, I've fried a couple Teensies, possibly by applying 12V to Vin or it could have been the heat of lead-free soldering. And it is extra work to use level converters and I2C pullups. Never fried an Arduino. However, for a repeat project or use in a commercial product, the combination of low price, high performance, manufacturing quality, and product support is unbeatable I think.
 
Status
Not open for further replies.
Back
Top