problem running teensy 3.2 on external power instead of USB

J

jrdarrah

Well-known member
I found this odd behavior while trying to debug some code to detect a USB connection. I kept removing code and hardware to get to the root cause of the teensy 3.2 not running the sketch if powered by a 5V source and not the USB. I did cut the trace and have diodes to protect each power source. I've attached the schematic. The battery power circuitry consists of 2 AA batteries feeding a Pololu 5V step up regulator #2564. it is JP5 in the schematic

https://www.pololu.com/product/2564

The battery + is routed to an isolated switch built into the headphone jack SJ-435107RS. When the connection is made the battery voltage goes to the input pin of the step up regulator. That output feeds a diode D1 tied to VIN.

To eliminate the USB itself as the problem I compiled this sketch with no USB selected in the IDE.

Code: 
// battery power problem
// 4/13/22 Jim Darrah
#define BlueLED 16     
#define RedLED 17               
void setup() {
  //To save power set all 34 Teensy 3.2 IO pins to output
  for (int i=0; i<34; i++) {
    pinMode(i, OUTPUT);
  }
  delay(1000);
  digitalWrite(RedLED, HIGH);             // LED off to start
} 
void loop() 
{
  
}

What happens makes no sense to me.

If I connect the USB connector the sketch runs fine including the delay before the red LED comes on.

With the USB cable in place, if I plug in the headphone jack to enable battery power and unplug the USB connector it continues to run. That tells me that the battery power circuit is working properly.

From a powered off state, if I only plug in the headphone jack to run solely off battery power I get either no red LED, an immediate red LED (no delay), or for no apparent reason an immediate blue LED.

I rigged a test harness to allow me to scope and measure the voltage of VIN and VUSB. VUSB comes in at 5V and VIN about 4.67V which allows for the BAT54C Schottky Diodes voltage drop. When I look at the VIN as powered from the battery circuit I see no noise, just a clean signal at the correct voltage.

I'm out of ideas except maybe the startup of VIN from the battery only is too slow or glitchy since it depends on the switch built into the headphone jack. I saw nothing obvious noticed in the scope. Any suggestions on what to try would be greatly appreciated.
 

Attachments

  • Teensy 3.2 carrier board.pdf
    42.5 KB · Views: 41
Since the test program doesn't do anything, how do you know it still runs on battery?

My initial thought was that some i/o pin(s) was powered up first and the Teensy entered a latch up state. Looking at the schematic, I guess that could only be pin 22 and you could test that idea by removing R5.
 
rcarr said:
Since the test program doesn't do anything, how do you know it still runs on battery?

My initial thought was that some i/o pin(s) was powered up first and the Teensy entered a latch up state. Looking at the schematic, I guess that could only be pin 22 and you could test that idea by removing R5.
Click to expand...

Thanks for the quick reply. Agreed this sketch does nothing but I know it is running because of the delay(1000). When powered via USB it is noticeable. When powered by the battery whatever it does, no light, red LED, or blue LED is immediate.

It may be a latch up situation but I need to keep the circuitry (R5,R7,R8,R9) in some form to allow the target sketch to monitor voltage so I can alert the user to change batteries. Maybe adding a capacitor to slow down the voltage rise enough to allow the processor to fully start before checking the io pins. I'll do some searches on teency latch up and monitoring voltage to see if anyone else has had this sort of problem.
 
With the USB cable in place, if I plug in the headphone jack to enable battery power and unplug the USB connector it continues to run. That tells me that the battery power circuit is working properly.
Click to expand...

How do you know it still runs in this ^ scenario was what I was questioning.

You could try single shot triggered mode with your scope and try to catch the power up of your switching power supply.
 
I'm assuming it still works because the red led stays on and has never given the no LED or blue LED symptom when disconnecting the USB cable.

My scope is an old Tectronix so with single shot the trace wouldn't hang around long enough to see if there are glitches.

For your theory about latch up of pin 22 (or 23) I did some looking for how others monitor input voltage which was the problem I was trying to solve when I added the circuitry around pins 22-23 and found this old forum thread.

https://forum.pjrc.com/threads/26117-Teensy-3-1-Voltage-sensing-and-low-battery-alert

If that method works I can delete the resistors R5,R7-R9 to test your theory.
 
I tried several things today. Since the software detect of VIN looks like it will work I deleted the resistors R5 & R8 from my board (see the schematic I attached earlier) to disconnect them from pins 22 & 23 in case they were coming up before the processor started and causing a latch up condition. Didn't help. I had a 100uf cap on the output of the step up regulator that when I measured it, 1 saw 1.7v and slowly discharging. I replaced it with a 10uf to have it discharge more rapidly. I classify this as a random guess technique. Didn't help. I also modified the sketch to alternate red-blue so there would be visual proof that the sketch was really running. The new sketch -

Code: 
// USB Status detection sstudy
// 7/30/21 Jim Darrah
#define BlueLED 16               // indicator when MIDI is enabled, only used with USB connection so no power drain
#define RedLED 17                // redLED
void setup() {
  //To save power set all Teensy 3.2 IO pins to output
  // void InitAllPins()
  for (uint8_t i = 0; i < CORE_NUM_DIGITAL; i++)
    {
      pinMode(i, OUTPUT); 
      digitalWrite(i, LOW);
    }
} 
void loop() {
 digitalWrite(RedLED, HIGH);
 digitalWrite(BlueLED, LOW );
 delay(1000);
 digitalWrite(RedLED, LOW);
 digitalWrite(BlueLED, HIGH );
 delay(1000);
}

As a last resort i lowered the clock from 96 mhz (overclocked) to 72 mhz and now it reliably runs on either battery or usb. For my application I really need the higher clock rate

More digging found this forum post -
https://forum.pjrc.com/threads/67919-T3-2-power-up-issues

That had a problem similar to mine. It worked well on USB but this application failed to start about half the time when run on external power.

The key replies said - " Looks like putting a short delay (an empty loop) in startup_early_hook() fixes the problem." and "I tried a few places - setup() was too late. Even startup_late_hook() was too late." This explains why the delay(1000) I tried in setup() didn't help.

Before I add the startup_early_hook and the empty loop to my program so I can try to run at 96mhz can anyone shed some light on startup_early_hook? I'd like to learn more
 
I wanted to close this thread out with a summary of what didn't work and what worked, Most of the time.

After experimenting I finally decide that I have a slow power supply. I tried adding delays in startup(), startup_early_hook(), startup_middle_hook(), and even startup_late_hook(). None of those changes allowed the processor to start on battery only. My 2 AA batteries are up converted to 5v via a pololu module. It has a bad ripple without smoothing capacitors added. To see if the 100uF cap I have on the 5V output was slowing things down enough to prevent the processor from starting properly, I removed it. Didn't fix the problem so I put it back. On one of the "slow power supply" threads I saw where a 1nf cap on the reset would fix the problem but it messed up being able to program via the USB connection. For me, that was a non starter. What I did do that allows it to boot from battery about 99% of the time was to drop the clock from 96 mhz to 72mhz. Every once in a while I have to try to start it again. So far that has workedl Thanks for the answers to my request
 
You must log in or register to reply here.
Back
Top