Teensy 4.1 doesn't boot with VBAT applied. No v3.3 generated.

S

SmittyHalibut

Member
This seems counter to everything I've seen with regards to VBAT and the boot up process for the 4.1, but...

I just switched to the 4.1 (from the 3.5) for a project. I am feeding it 5v through Vin, and using the 3.3v it generates to drive a TFT display, an audio CODEC, and a GPS. I am _NOT_ feeding 3.3v into the Teensy from outside. I have a CR2032 socket connected to Vbat, and also to Vbat on a GPS which is connected to the Teensy via serial and PPS GPIO. But that's the only interaction with Vbat.

If there is a CR2032 in the battery holder, and I apply 5v to Vin, it might boot or it might not. More often not. When I poke at the Teensy with a volt meter in this state, I see 5v on Vin, but I do NOT see 3.3v on any of the 3.3v pins.

However, if I remove the CR2032, it boots reliably. There's no obvious voltage sag or other indication I might be pulling too much current.

This seems counter to what I've read in several places on this forum, and in the boot-up sequence documentation: https://www.pjrc.com/store/ic_mkl02_t4.html Is it possible that Vbat through the GPS through the GPIO pins to the Teensy is bleeding too much? Remember, the GPS is powered off the 3.3v from the Teensy.

Let me know if there's any other information that would help debugging this. Thanks for your help.

-Mark
 
Is anything connected to the On/Off pin?

If that pin is pulled low for several seconds, the 3.3V power gets turned off. Without a battery on VBAT, there is no way for the power management circuitry to remember the on/off state, so power cycling always causes the chip to boot up. But with VBAT, if you've accidentally turned off the power using the on/off pin, it will remain in the off state until you again pull that pin low.
 
Oh, for the sake of Pete. I’m not sure I noticed the transition from Reset (3.5) to On/Off (4.1). I believe that pin is disconnected entirely. Is it active low for On?
 
SmittyHalibut said:
Oh, for the sake of Pete. I’m not sure I noticed the transition from Reset (3.5) to On/Off (4.1). I believe that pin is disconnected entirely. Is it active low for On?
Click to expand...

Reading Paul's p#2 and just testing with DVM to confirm:
> On/Off must be held HIGH for normal operation, in the current state
-> pulling On/Off LOW will toggle the run state:: to OFF in ~5 seconds when ON, or to ON in about 0.5 seconds when OFF

This is the same as PROGRAM PIN that is normally High and active LOW

Good note Paul - using the battery and having the On/Off state HELD showed up during Beta ... at least here ... and even when knowingly connected it can be off-putting.
 
PaulStoffregen said:
Is anything connected to the On/Off pin?

If that pin is pulled low for several seconds, the 3.3V power gets turned off. Without a battery on VBAT, there is no way for the power management circuitry to remember the on/off state, so power cycling always causes the chip to boot up. But with VBAT, if you've accidentally turned off the power using the on/off pin, it will remain in the off state until you again pull that pin low.
Click to expand...

Ok, just checked my schematic. I have On/Off pulled to 3.3v with a 10k. If I'm reading "the 3.3v power gets turned off" correctly, then it will never turn itself back on because it's never coming high again.

Can I leave it floating? Or should I pull it high to an external power source? Is it 5v tolerant? Can I pull it up to Vin? (Worst case, I can put a divider on Vin and still feed it with 3.3v.)
 
defragster said:
T_4.x pins are not 5V tolerant - including that one.
Click to expand...

Ok, got that.

But if I don't intend to use a power button on this device (at least, not that one), should I leave that pin floating? Or pull it up to an external 3.3v power source? Or, should I expect pulling it up to the internally generated 3.3v power source (like I'm doing now) to work (but it's not)?
 
We are facing the same issue (or very similar) with some of our Teensy 4.1 boards.

Just for a quick context, we have hundreds of Teensy 4.1-based dataloggers/signal acquisition systems with custom PCBs. These dataloggers operate continuously and often in remote locations, powered by batteries, solar cells or DC sources which supply 12V. In a nutshell, the dataloggers are powered by 12V which is then converted to 5V by a buck regulator. The 5V feeds the VIN pin. The On/Off pin is left floating. We use the VBAT pin connected directly to a CR2032 battery to keep the date and time

We've had three instances of the following: The datalogger stops working. On checking, we find that the 12V and 5V voltages are normally active, but there is no 3.3V that should be produced by the Teensy 4.1's LDO. There are no shorts on the board. Removing and reinserting the main supply voltage (12V) does not solve the problem. However, if the CR2032 battery is removed, the Teensy instantly switches on the 3.3V regulator and boots up normally, returning to operation.

It seems that Teensy's boot sequence got stuck at some stage and can't proceed. There is also a mystery as to why the regulator that was working continuously suddenly stops working and producing 3.3V, and only by removing the voltage at VBAT can we resume operation.

Could someone please give me some light or direction to help investigate this problem?
 
@VictorFS
With VBAT voltage, If the On/Off triggers an OFF it will stay OFF until the ON sequence is completed - or the VBAT voltage goes away.

It seems like the floating pin may have been triggered?
 
Hi @defragster, thanks for your input.
It seems weird to me that the floating On/Off pin would have been triggered, specially when its so uncommon with our Teensies.
In any case, considering that I don't need the functionality of the On/Off trigger in my project, VBAT pin is always around 3V due to the CR2032 battery and I want Teensy to turn on and remain on while there is 5V on the VIN pin, what is the wiring recommendation for this pin? Should I pull it low, high or leave it floating?
 
I can well imagine that the VictorFS systems operate in environments and climates where water may condense where the on/off pin is exposed. Or where insects can creep into the datalogger units and do a short circuit with their body. If water or beasts or mold forms a << 10k bridge to GND, say to the uSD connector metal nearby, or to nearby other output pins that are driven low, then expect this type of trouble.

Pulling on-off high via a low ohms resistor might help. But i’m not sure if that then must be pulled to VBAT pin.
 
Check this code by Frank B : https://github.com/FrankBoesing/T4_PowerButton

It allows capturing the On/Off press (when ON of course) - and the switch to OFF can be ignored IIRC. I'm not sure how the On/Off works when unpowered with only VBat power without hooking something up.

One of the examples will allow trapping the On/Off press and the code can print that event and IIRC ignore it.
 
It may, or may not be related, but for one of my systems T4.1 does only boot (from hibernate or power plug-in), if Program pin is pulled high. I do this with a 68 k resistor. It seems that the boot chip, to which prog pin is connected, inhibits boot. To test this simply touch prog pin t with VBAT.
 
@sicco
You're absolutely right about the environment and climates where those systems operate. However, the Teensy and all other electronics are placed inside a IP66 enclosure, so no water or insects can contact the electronics. Regarding condensation, it also doesn't happens because the surfaces inside the enclosure are hotter than the air outside due to the natural heat dissipated by the electronics. In any case, whenever the problem occurred, we checked internally and no insects, dirt or signs of water were detected.

@defragster
Considering that the problem I'm having is in fact an accidental triggering of the On/Off pin for some reason, I believe that Frank's library can help prevent the shutdown. I may be wrong, but I think that with VBAT always present, the On/Off state is “remembered” by the system, so if the system were prevented from shutting down while there is power, when there is no power to Teensy (only VBAT), the remembered state will be “On”.
I'll try to test this as soon as possible. Although my initial wish would be to prevent the “On/Off” from being triggered in the first place.

@WMXZ
This behavior is curious and may indeed be related to my problem. However, I can't reproduce it (at least not yet). We have hundreds of systems with Teensy running 24 hours a day and this has only happened to us a few times, on different systems, and usually in remote or distant locations where I can't get immediate access to try to understand or run tests. Do you have any idea how I could force this boot prevention behavior somehow? Anyway, would it do any harm to simply add a 68K ohm pull-up on the prog pin to 3.3V on all our Teensies?
 
IP66 in the tropics is not keeping the water out. See e.g. https://electronics.stackexchange.com/questions/388866/moisture-trapped-in-ip66-enclosure
The issue is that despite of the rubber seals, such boxes breath in and out on a daily basis. During the day in full sunlight the internal atmosphere heats up so the air pressure inside goes up. But at night they cool down, and pressure falls. The IP66 rubber seals, or IP66 cable glands are easily compromised. Or miniscule pin holes simply equalize the pressure outside and inside. So then you suck in warm air with water in it. But when cooling down further the water falls out, and builds up inside the box. In wet tropical climates yet then get cycles where after some time the boxes accumulate water.

On the ONOFF T4 library code: the i.MX RT1060 Processor Reference Manual suggests that there are many options for disabling the ONOFF feature, or simply not connecting a hardware pin PAD to the functional ONOFF input. But I don't see that being exploited in this library.

Related topic: from that library, this code:
Code: 
FLASHMEM __attribute__((noreturn))
void arm_power_down() {
  SNVS_LPCR |= SNVS_LPCR_TOP; //Switch off now
  asm volatile ("dsb");
  while (1) asm ("wfi");
}
is that really best practice?? I mean the while(1), does that not mean that the CPU simply keeps running on the 32KHz clock?? Is that a hint maybe why CR2032 cells and T4 last maybe months but not >3 months? I'm starting to think now that not all that could be done is being done to make the CPU really go deep as possibly practical sleep mode with only RTC ticking, but everything else turned off. If for example Ethernet, ADCs and many more peripherals stay on, and even CPU keeps ticking its while(1) loop, then...
 
sicco said:
is that really best practice??
Click to expand...
TOP stands for turn-off power. As soon as that bit gets set in the LPCR register the power to the CPU (and practically everything else powered by the 3.3V regulator) gets turned off. The rest of the code doesn't run.
 
@sicco
I agree that the possibility of water entering the equipment's enclosure, as you describe, is valid and can indeed happen. However, in the cases we've had, the equipment was opened for verification and the inside was completely clean and dry, with no sign of water or insects. In the two most recent incidents we had, I checked the weather and the weather was dry and hot in the region at the time.

In addition, there is another fact that makes me believe that the problem in our case has an electronic origin: Last week we had two Teensy dataloggers that presented this problem at the same location / station. On site, the power source is a solar panel coupled to a PWM charge controller and a 12V lead-acid battery. There was a continuously operating datalogger at this location that suddenly had the problem. It was quickly replaced by another identical datalogger, with the same internal electronics (but keeping the 12V power supply system that existed at the site). This new datalogger operated for approximately 3 hours before the same problem occurred. In both cases, Teensy was only able to start up after removing the CR2032 battery from the VBAT.
After laboratory analysis, it was found that no electronic components had been damaged. In any case, the solar PWM controller and the solar board were replaced and taken away for analysis, but we still haven't found any problems with these components, which appear to be working normally.

At the moment, my guess would be that the PWM charge controller may, in the course of its operation, present some noise, overload or something of the sort that is not properly filtered by my internal electronics and somehow shuts down the Teensy. But not completely, keeping it in a stuck state, unable to boot up again. I think it would be possible to mitigate this effect with some change to my circuitry, and I'm willing to do it. However, unfortunately the problem is rare and I can't reproduce it in the lab to investigate further.
 
I'm also considering some issues regarding the Teensy LDO regulator NCV8186AMN330TAG, which is present on all my current Teensy 4.1 that failed somehow. In addition to the issue described on this thread (regarding VBAT preventing boot), which happend to me around 3 times, I've also had around 10 occasions where the LDO failed completely and shorted 3.3V to ground, killing the Teensy. I've searched the forum and found many interesting topics including those:

5V 3V3 VUSB power supply struggles - Teensy4.1 - what kills my NCV8186AMN330TAG ics? (@sicco , btw did you manage to find a final solution to your problem?)
Teensy 4.1 updated LDO causing power supply problems (here we find out that this part does not have proper soft start as the previous TI LDO)

I was wondering which kind of electronic changes I could make to my board in order to avoid some of this issues and make the system more robust. Add a Schottky diode from 3.3V to VIN in order to avoid reverse current?
 
Maybe you have solder flux leftover or splashes that form a resistor, at delicate points such as nearby the onoff pin, and at points where 5v or even 12v may hit Teensy pins (via flux leftovers) that cannot tolerate that?

On the LDO, in that particular project i always have a Schottky diode from T4 3v3. to 5v in. Never had problems since.
 
Splashes near the on/off pin would be unlikely to happen, since that among the 5 pins below the SD card slot, we only use/solder the VBAT pin, which is as far away as possible from the On/Off pin.

I also think it unlikely that this is the cause for two reasons: 1 - The datalogger with this Teensy and board operated for months without any problems before this failure occurred. I believe that if there had been this accidental formation of a resistor with splashes or solder flux, the problem would have been noticed earlier. 2 - As soon as this datalogger malfunctioned, it was replaced by another of the same model. After a few hours, the same problem occurred. We have no previous records of failures due to soldering errors in more than 500 pieces of equipment of this type that we use, so the chance of this happening twice in a row at the same location would be low.

In fact, reason 2 actually leads me to believe that there's some kind of electrical problem that my PCB with the 12 to 5 volt buck regulator and/or the Teensy can't handle well. Perhaps too high an inrush current? Lack of softstart? Reverse current? I'll try to investigate this with the oscilloscope.
 
You must log in or register to reply here.
Back
Top