Teensy 3.2 won't boot on battery power

Status
Not open for further replies.

justgary

New member
Hi -

I know that this topic has been covered before, but I can't get my Teensy 3.2 to boot except when it is powered via a computer USB port. More specifically, it won't even boot when powered by a USB battery source. It won't boot with 5V on Vin from my bench supply or 3.3V on the 3.3V line from my bench supply. It will only boot when the computer is powering it.

I am watching the VUSB, 3.3V, PROG, and reset lines on a scope and can see that the VUSB power comes up first (with slightly different response, depending on the power source), then the 3.3V starts coming up about 30 uSec later, then reset comes high 100 uSec after the 3.3V line gets above 2.45V or so. Prog comes high about 30uSec before reset. This consistently happens no matter the power source.

I tried the capacitor from ground to reset trick, and played with different capacitors, but no luck. In fact, I can't get reset to work even when I ground it if the power source is anything other than a computer port. Grounding reset works fine if it is powered from a computer.

Yes, I'm running a power up blink so I can see the LED come on and blink when it boots correctly.
No, the VUSB/Vin jumper is not cut.
I don't have any other devices attached.

Is the boot device able to keep the processor from running even if reset is high?

DS0005.PNG
Boot from Computer USB - Teensy boots.

DS0006.PNG
Boot from Large USB Battery Pack - No joy.

DS0007.PNG
Boot from Small USB Battery Pack - No joy.

Green = Vin; Yellow = 3.3V Out; Pink = PROG; Blue = Reset (Test point on back of Teensy 3.2)
 
Any chance it really is booting properly, but there may be something like a "while (!Serial) ; " in your code that's waiting for USB?
 
Any chance it really is booting properly, but there may be something like a "while (!Serial) ; " in your code that's waiting for USB?

Paul -

Thank you for the very prompt reply.

I did in fact have a USBSerial based printf() hiding near the top of my code (I'm using mbed) that I had left in place even after moving to an LCD display. Removing it got it booting. Well, it *was* booting already, so I owe you beer. Thank you very much.

I spent most of the day looking at reset lines, reading about battery boot problems, etc., but I never even thought about the USB print. This is one of the small differences between the mbed boot loader and yours, since mbed is actually writing to a UART on the processor and doesn't fail if the USB port isn't occupied.

Since I have you, I'd like to tell you thanks for the great products you have brought to the market. I have quite a collection, but tend to use the ones that are easy to use with mbed. The primary reason is the multitasking RTOS that comes with it, but the secondary reason is that I never could get used to the Arduino "sketch" model and the way it globs everything together before compiling. In any event, I have a pair of new Teensy 4.0 boards still in the bag that I need to try out. Next project, perhaps.

Best Regards,

- Just Gary
 
Interesting MBED wasn't in the intro post …

Sure, I'll take your troll bait. Tell me how that would have changed the outcome of the question?

I banged my head against the issue for a good while, and searched the internet for possible answers, and found many threads about the reset line releasing too fast, needing to add capacitors, etc. Not one of the threads I found mentioned a hang on USB. They all mentioned bootloader issues and the reset line. I documented what I believed was the foundation of the issue and left out all of the interesting but unimportant details that would have simply added clutter to the question.

I suppose it's easy for you to up your post count with a comment after a problem is solved, so I'm glad you got an opportunity to do that. I'm also glad that Paul nailed it without any mention of mbed in the intro post, which tells me that I included enough information for someone to answer the question.

We all benefit from the occasional "confessional debugging," where the simple act of explaining how our code works helps us see what we did wrong. That's the primary reason for this forum, isn't it? Perhaps the next person who hangs their device when booting from a battery will read this thread and fix their own problem without bothering you. Wouldn't that be great?

Regards,

- Just Gary
 
We see this problem pretty regularly here, since most of the Arduino examples have "while (!Serial) ;" and people forget or don't know to remove that code. If you search for the right terms, I'm sure you'll find many threads. It's one of the most frequently asked questions.

We also pretty regularly see questions without showing the code to reproduce the problem. Before you get too hostile, please consider we have "Forum Rule" in red at the top of every page. When we see the actual code, and there's a "while (!Serial) ;" and the reported problem is doesn't boot without USB, you'll get a very quick answer here because everyone who uses this forum regularly has seen that over and over.

But we generally do assume you're using Arduino if you don't say otherwise. In many cases, it does indeed make a huge difference. For example, if you try Arduino you'll discover Serial.printf() does not hang waiting for the USB port. So if you had shown your code as our rule says you should do, and withheld that you're building with mbed's code, nobody (not even me) would have thought of this being the cause. Normally Serial.printf() doesn't do this.
 
Paul -

I understand that the same questions get asked over and over. I tried to research the problem thoroughly before I posted, and the responses I found led me to believe that the bootloader/hardware may be the cause. One can quickly go down a rabbit hole based on the search terms used and the answers one sees. Since I truly thought it was a firmware or hardware problem, I didn't post code.

What got me was the apparent side swipe after the problem was solved. Knowing the answer tends to bring a clarity that makes that kind of comments easy, I guess.

Sorry I broke the rules, but it does seem that I presented enough information for you to kick me in the pants. I have written a lot of embedded real-time code since 1984, and I'm generally pretty good at debugging with an LED and an oscilloscope. My problem here was that turning on the LED was the *second* line of code. It's now (and forever more) the first. Lesson learned.

Thanks again for your help, and for all of your great work.

Regards,

- Just Gary
 
Status
Not open for further replies.
Back
Top