Issue: Teensy 3.3 randomly boots into bootload while no USB is connected

Status
Not open for further replies.
I have a Teensy 3.2 that seems to randomly, 80% of the time, power up into bootloader, or at least never runs user code. It's powered externally by 3.3V applied to the 3.3V pin and the VUSB jumper has be cut. There's no USB connected when this happens.

If It powers up this way, I usually have to connect it to my computer, run the teensy bootloader and tell it to start user code. A simple power cycle doesn't fix the problem.

Any suggestions on how to fix this? I need it to reliably enter user code mode at power up with no USB connected.

I've looked at the schematic and releaized there's a second processor on board, an M0 that sits between the a USB pin, the programming pin and a reset pin on the M4. What's it's function during boot up / programming?
 
Last edited:
After searching the forums, I've tried adding delays to my setup

void setup(){

//some delay at the front
delay(100);

//setup pins
digitalWrite(RELAY_EN, LOW); //Drive LOW first to keep disabled.
pinMode(RELAY_EN, OUTPUT);
pinMode(OUTLATCH, OUTPUT);
pinMode(TROLLEYOUT, INPUT);
pinMode(TROLLEYIN, INPUT);
pinMode(TELESCOPEOUT, INPUT);
pinMode(TELESCOPEIN, INPUT);



SPI.begin();
//setup serial
Serial.begin(115200);
//setup LCD
lcd.begin(16,2);
//setup CANbus
can.begin();
//some delay at the middle
delay(100);

Serial.println("LRD Controller Booting");

lcd.print("LRD BOOTING");

//start CanOPEN
//send CANOpen init message to NOVA and motorcontrollers
//this will get the NOVA to start sending messages and start our control loop
sendCanStart();

//prime State Machines
state = INIT;
movement = NONE;

//some delay at the back
delay(100);
}

And I'm never doing a whilt(!Serial) so these don't seem to be the issue.
 
I've loaded the basic blink program and can confirm the same behavior, most of the time it fails to start the blink program from cold boot. Connecting USB, hitting the program button and then clicking reboot in the window starts the blinking.
 
Any chance you can try a much simpler program, perhaps just the LED blink example?

Perhaps some sort of hardware problem is causing this, in which case you'd see the simple LED blink fail to start blinking the LED. Or perhaps it's related to some complex software issue, if the LED blink always starts up properly on your hardware.
 
Any chance you can try a much simpler program, perhaps just the LED blink example?

Perhaps some sort of hardware problem is causing this, in which case you'd see the simple LED blink fail to start blinking the LED. Or perhaps it's related to some complex software issue, if the LED blink always starts up properly on your hardware.

Yep, tried the blink example with the same result. More than half the time it fails to start blinking.
 
Well this is odd. I've scooped my 3.3V rail to see what's going on. Most of the time, this is the startup. It's a fairly linear voltage rise that takes about 5ms to get to 3.3V.

NOPE.PNG

And it always seems to NOT boot with that startup curve.

The times it DOES work, this is the startup on the power rail:

WORKS.PNG

I'm at a loss on this one. A)Whats causing that off startup spike (its a RECOM switching regulator with a 100uF cap on the output) and B) why does that startup spike make it work!?!?!?!
 
Yes this seems to be a power supply issue, the Teensy doesn't seem to like that 5ms ramp up. If I use an external power supply with instant power up it always boots. Is this expected? Do the ARM chips get upset with slow rise times on power pins?
 
Freescale errata:
http://www.nxp.com/files/microcontrollers/doc/errata/KINETIS72MHZ_2N36B.pdf

e6665: Operating requirements: Limitation of the device operating range
Description: Some devices, when power is applied, may not consistently begin to execute code under
certain voltage and temperature conditions. Applications that power up with either VDD >= 2.0
V or temperature >= -20C are not impacted. Entry and exit of low-power modes is not
impacted.
Workaround: To avoid this unwanted behavior, one or both of these conditions must be met:
a) Perform power on reset of the device with a supply voltage (VDD) equal-to or greater-than
2.0 V , or
b) Perform power on reset of the device at a temperature at or above -20 C.
 
The weirdness continues. Another project with similar, but smaller, power supplies always boots fine, and I probed it to see a 1.5ms rise time, still linear. If I load this design with a 5 Ohm resistor, the rise time, still linear increases to 15ms, but the Teensy ALWAYS WORKS in this case.

What the heck, 1.5ms rise time, OK, 15ms rise time OK, but 5ms rise time NO WORK!

Grrrr
 
Might have something to do with the crystal oscillator circuit, strange though that there's a dead window in between fast and slow power ramps. Maybe the clock starts at a lower voltage than the CPU can reliably work, but with a very slow ramp the clock also takes longer to build up the output signal past the logic theshold? Just speculation and doesn't fix your problem. You may need a separate power-on-reset chip to be reliable, if you can't ensure the powerup ramp avoids the bad region in timing.
 
Hello,

I was about to start a new thread but then found this when searching 'Recom'. I want to use a Teensy 3.6 on a motorcycle for a data logger and thought I would use a Recom R-783.3-0.5 to provide the 3.3V from the motorcycle 12V. On my test bench I can power it with a 12V wall wart (sems to be providing 15V) but it doesn't run my code until I push the reset button on the teensy, then things are fine. When I move it to my car for testing the reset button doesn't help at all and maybe 1 out of 10 tries to power things up the teensy runs my code. I seem to have the same approx 5ms power-up time when I scope the 3.3V on my bench. I have not done the same using 12V in car (and have not used motorcycle at all) due to the winter weather working outside.

I have the 3.3V also powering a BT adapter, accelerator board and a GPS board and all of them seem to be powered up fine.

I am thinking I might change the power to a 5V feed into the Vin of the Teensy and then power all the 3.3 via the teensy and see if that resolves any of the powering timing, not sure if feeding 5V into teensy would help/change anything.

Any other thoughts on things to try? I want the teensy to power up and load my code with the key on of the bike and I wont have access to the mounting location of the teesey to fumble around with the reset button etc.

Thanks for any suggestions
Jeff
 
Jeff,

I solved it be reducing the size/current output of the Recom regulator. I was using the large 3A one, and I went down to the 500mA one and the problem went away. But it looks like you are using that one too. Weird. I wonder is the chip on the Teensy 3.6 is different in behavior to these startup slopes.

You've got a few options. You could power the teensy at 5V, and draw 3,3V off of it. Be careful to not overload the 3.3V output, and consider the extra heat the linear regulator on board the teensy will add to your system.

Or you can design your Teensy carrier to have one of those startup reset chips. They exert a reset on the MCU until the voltage comes up and a time delay passes. Unfortunately since the reset pin isn't broken out well on the Teensy (it's only a test pad on the 3.2) you have to use a pogopin on your carrier to make contact with it.
 
Thanks for the reply. I am using the 500mA version and from datasheets the items connected to the 3.3V (other than teensy) is currently about 75-80mA. I probably have a few other sensors < 10mA total to add. So I will be under the 250mA limit on the sheet for the teensy. But since they were all 3.3V I figured the Recom reg would be a good choice. I guess I will continue with my 'supply 5V' using a Recom 5V to teensy and see what I get since I have the parts to do that test. I suspect heat on the Teensy regulator shouldn't be an issue though I will monitor it.

If that works it will at least let me do my testing and think about other options.

Thanks, Jeff
 
I'd like to recreate the problem here. But I don't even see part numbers for the components used, so I have no idea where to even begin...

I solved it be reducing the size/current output of the Recom regulator. I was using the large 3A one, and I went down to the 500mA one and the problem went away.

Any chance you can give me the part number of this problematic power supply? And maybe a photo or accurate schematic of how it was actually connected, maybe even some details about what was sources its power (those details can matter).

Or maybe you could send me the one that didn't work?
 
Paul,

The item I had a problem with is Digikey PN 945-1661-5-ND (http://www.digikey.com/products/en?keywords=945-1661-5-ND) which is the 500mA version and is the version that seemed to have solved the issue for the OP. The datasheet I used for details is at https://www.recom-power.com/pdf/Innoline/R-78xx-0.5.pdf though noticed digikey points to https://www.recom-power.com/pdf/Innoline/R-78Exx-0.5.pdf

I have 2 of these and both acted the same way so I don't think it's the actual item, if anything it's the implementer, so you could probably get one from digikey or mouser faster than postage from Canada (though I am willing to send one). I also have the 1A model (digi PN 945-2409-5-ND) but didn't try it. Last night I ended up using a 5V version of same item and feeding the Vin of the Teensy and the sensors are powered off the 3.3V of the teensy. I have not really done any testing yet to confirm that it will be better. It booted first try last night but only tried the once so far.

the problem configuration:
- source is either a 12V 'wall wart' (actual output seems to be 15.23VDC) or a 12V cigarette lighter plug in the car (have not confirmed actual voltage)
- power into a 2.1mm barrel jack
- 10uF cap between vin and gnd of Recom R-78E3.3-0.5
- GND and Vout from Recom R-78E3.3-0.5 to a pre-made PCB prototype board
- the 3.3 powered Vin of 2 TMP006 sensors, 1 10DOF board (MPU6050 based), a RN42 based BT module and a Venus838FLPx based GPS module as well as the 3.3 pin of the Teensy 3.6
- scope showed power up to 3.3V was 5.2ms on the 'wall wart'
- I realized why pressing the program button worked on the test bench as I usually connect the USB but had the Teensy programmer in the background and the code was open. So it seems it was programming each time. Disconnecting the USB ended up with the same experience as in the car - no program started most of the time
- about 5-10% of the time I could disconnect power and reconnect it and the program would start

Jeff
 
Hi Paul, as I mentioned before, I have used a https://www.amazon.com/Castle-Creat..._1?ie=UTF8&qid=1487688394&sr=8-1&keywords=bec

On one of my hexapods for awhile and it has powered, several different Linux boards (RPI, ODroid, I believe Edison). With these boards I often use one of my Teensy boards and power those boards up with them as well. Mainly with T3.2... So I tried it again simply connecting up to T3.2 board and it still works, It also worked connecting up to T3.5, but does not work with T3.6.

My latest tests were done with a 12v wall wart: I have used two of them from Trossen: http://www.trossenrobotics.com/12v10a-power-supply
http://www.trossenrobotics.com/p/power-supply-12vdc-5a.aspx

Simple wiring In my case I have the BEC input power wires connected to an AX servo connector (cut extension cable in half), so I plug the BEC into an AX/MX HUB, where it has a 2.1mm connector to plug the wall wart to and then connect the output from the BEC to GND and VIN on Teensy board...

If desired I could retry again with wall wart and/or with 3s lipo battery.

Edit: Forgot to mention, that I think it worked on the Original Round 1 T3.6 beta board...
 
Last edited:
Did you try a simple reset circuit that pulls reset low a for a few ms on power on ?

Try 10nF between reset and gnd, and 10K between 3.3v and reset. Maybe you can omit the resistor.
That's a very simple, but common circuit. There's a chance, that it is too simple.. :) In this case, im sure we will find a better solution.
 
Last edited:
Thanks Frank, I tried playing around earlier and the first attempt did not work...

As I mentioned, with my newer boards I have my own DC/DC converter on the board which works, so I have not played much since then with it. But if Paul is looking for an easily available circuit that does not appear to work with T3.6, but does work on others, then this would be one option.

Edit: For what it is worth the one I am using in at least one of T3.6 boards is: https://www.digikey.com/product-det...lutions-inc/OKR-T-6-W12-C/811-2179-ND/2199629

I have used a different murata 5v regulator on some other boards (DCDC_OKI-78SR), not sure I tried these yet on T3.6. For the one board I went with one with link as it outputs 6amp, which gives me lots of power to also power up RPI or Odroid... where the smaller one gives you 1.5amp
 
Last edited:
I am starting to think at some point I may have damaged something hardware wise with the startup of my Teensy 3.6. Even feeding 5V into Vin of the board seems to be hit and miss, the voltage reg seems to work as 5V into my Teensy 3.6 powers up my 3.3V sensors. But the code (even just Blink) doesn't run. On the other hand my Teensy 3.2 powers up every time with the same power circuit to run Blink code.

I have not investigated further, that will have to wait for the weekend.

Jeff
 
When you apply the power and blink does not work. If you then momentarily jumper the Reset pin to GND does blink then work?
 
Working from home sometimes has its benefits. Boring con-call so I did more review of my teensy 3.6 power issue. I didn't follow standard debug procedure .... I removed the sensors from my board but I never removed the Bluetooth and GPS items from the board when testing power. Too bad, it seems my Teensy 3.6 boots just fine each time if I remove the Bluetooth adapter.

Item in question is http://www.canadarobotix.com/bluetooth/rn42-xv-bluetooth-module-pcb-antenna (datasheet @ http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Wireless/Bluetooth/RN42XV.pdf)

I have 6 wires going to it.
RN41--------------> Teensy
pin 1 - 3.3V ------> 3.3V output
pin 10 - gnd ------> gnd
pin 2 - TX --------> pin 0 (RX1)
pin 3 - RX --------> pin 1 (TX1)
pin 12 - RTS -----> pin 20/A6 (used in code Serial1.attachCts)
pin 16 - CTS -----> pin 16/A2 (used in code Serial1.attachRts)

Even if Blink is the code on the 3.6 the BT module effects power up. So I need to look deeper at how the BT module boots up and what it send out those lines I suspect.

Thanks, Jeff
 
@Frank - yes, I tried it and it seems to work. Still trying to figure out why the BT adapter is causing the issues in the first place for my own curiosity but at least now it powers up consistently and I can also test my code in a moving vehicle between sessions of looking at the power issues

Thanks, Jeff
 
@Frank - yes, I tried it and it seems to work. Still trying to figure out why the BT adapter is causing the issues in the first place for my own curiosity but at least now it powers up consistently and I can also test my code in a moving vehicle between sessions of looking at the power issues

Thanks, Jeff

Great !
Do you a have schematic of this BT adapter ?
 
Status
Not open for further replies.
Back
Top