Teensy3.6 reset ssue while run on battery powered

Status
Not open for further replies.
A

ankit.vadict

Member
Hi,

We are using Teensy3.6 in our sensor and we are using battery as a power source. We are supplying regulated 3V from a stable source to Vin pin of Teensy3.6.
Generally it is working fine until sensor is not going to sleep. Problem occur when it is waking from sleep it automatically Teensy3.6 is reset itself. For debugging purpose we are monitoring the reset cause as well as LVD(low voltage detection) of Kinetis K66's core register. From this debug results we came to know that some time it giving low voltage warning detected and some time it reset the MCU. The reset cause we came to know that is reset due to low voltage.

Is there any way to change in Teensy hardware and we can solve the problem of low voltage warning and reset.

To avoid reset the MCU, what should I do? Any help require which can lead us to solve the problem of reset and low voltage warning detected.
@Paul please help or any input will be very good for us.

Thanks,
Ankit
 
Hello. Well you already know the obvious answer is that 3V is too low. Vin needs 3.6-6.0V. If you look at the schematic: https://www.pjrc.com/teensy/schematic.html, LP38691 regulates a 2.7 to 10V input to a 5V output, so it's capable of regulating your 3V input. There are two protection diodes before the input to the regulator - bypassing these would remove the forward voltage drop and this might be enough, although the regulator still drops up to 0.25V. Just my suggestion, but a higher battery voltage is probably a better idea. Also, I wouldn't regulate the battery voltage (what actually is it?), the regulator on board is already doing this - this might be the actual answer to your problems.
 
Last edited:
UHF said:
Well you already know the obvious answer is that 3V is too low.
Click to expand...

Yes you obviously right.

UHF said:
Just my suggestion, but a higher battery voltage is probably a better idea. Also, I wouldn't regulate the battery voltage (what actually is it?), the regulator on board is already doing this - this might be the actual answer to your problems.
Click to expand...

We have to power few other peripherals directly such as a zigbee radio, eeprom and other sensors. Teensy power is not sufficient to power all other peripherals.

As per Kinetis K66 datasheet: the MCU should work fine without resetting even with the lower voltages as 2.5V, while we can measure a continuous 2.6V on full load and 2.8V on no load.

If the 2.6V is given and still MCU resetting than what is the reason? We are reading the core register of MCU PMC_LVDSC1 and PMC_LVDSC2. In these core register we are reading two flags LVDF and LVWF. By observing these register we came to know that MCU getting low voltage. Can you say this Teensy's regulator could be the reason for getting low voltage?

I am putting series of question here.
1. Why we need 3.6v onward voltage when MCU can work with low voltage and do you think it is reason for reset in our case?
2. Is it can be related to particular battery we are using NiSocl2 battery as power source?
3. We are monitoring low voltage flag also and found that low voltage flag detected around reset event,we keep low voltage setting to low range. We also printing reset source at startup.
4. Do you think we should do other than this?
 
Last edited:
I just want to correct something I stated earlier, LP38691 is outputting 3V3 not 5V. This is what Teensy 3.6 appears to be designed to work with, 3V3, even if the MCU will go down to VDD 1.71V. Bypass the regulator as well?
 
Last edited:
UHF said:
I just want to correct something I stated earlier, LP38691 is outputting 3V3 not 5V.
Click to expand...

True that LP38691 outputs 3V3 and not 5V.

UHF said:
This is what Teensy 3.6 appears to be designed to work with, 3V3, even if the MCU will go down to VDD 1.71V. Bypass the regulator as well?
Click to expand...

NXP MK66 MCU sees this simply as 2.6V to its VDD pins. I guess it will not differentiate between Teensy or any other Board unless there are any specific power-related configurations done that it can work only on 3.3V. So, given that VDD can go down to 1.71V, the MCU should still function as normal with 2.6V at its VDD pins.
 
On teensy3.6 LDO LP38691 which is onboard and getting output from it is 2.6V to 2.9V. I checked the PMC(Power Management Controller) module and in this module all the setting are at low voltage default. The LVDV(LVD trip point voltage) bits in the MCU is also set at low voltage(LVDV = 00). At the same time low voltage warning voltage select also at lowest level(LVWV = 00). If the supply is given to MCU betweeen 2.6V to 2.9V then why the MCU is giving the warning related to low voltage detection by observing the flags of low voltage warning. Some time it also reset the MCU.

@Paul: Can you please tell why this things happened? Why the voltage is going too low from the 2.6V to 2.9V? Kindly share your input will help us here.

Thanks,
Ankit
 
Short of an answer from Paul ... can only wonder about other active/essential elements on the PCB. What power does the bootloader MCU see? Is it sending a reset? The crystal or other?
 
Auto-reset issue

@WMXZ: How do you go to sleep?
AFAIK, wake-up from deep sleep is reset MCU[/QUOTE]
=> We are waking up on RTC interrupt. We are using snoooze library available, and it is working perfect.

@defragster: Short of an answer from Paul ... can only wonder about other active/essential elements on the PCB. What power does the bootloader MCU see? Is it sending a reset? The crystal or other?
=> The voltage will be same as that of Vin pin because VDD pins of both the main NXP MCU and bootloader MCU is powered from the same source. Is there a way we would able to trace the voltage at bootloader, as we are seeing Low voltage related bits and warnings set? Didn't get you on last two points - please help us in understanding?

We would like some inputs so that we could look forward on our sensor board for this auto-reset issue. Is it related to interfacing with Teensey (will Teensey work fine having 2.6V in our case), or the battery we use is not consistent? What else can be planned in firmware which can help us to trace the cause and resolve it.
 
[Problem Resolved] - Posting the solution for community help.
- The problem was occuring while supplying power from Li-SoCl2 battery, which tends to show a few uS voltage drop when the Teensy wakes up from deep sleep.
- We tested with an external 5V adaptor stable source (mobile charger) and found that the reset events doesn't occur.
- To go back to the battery, because that is what we wanted to use, we added couple of delays (few mS) while initializing several peripherals on the board. By doing so, the battery gets sufficient time to settle down the output voltage to a stable value.
- One other solution could be to change the operating frequency in run time, however - from few other threads, it looks like this is not very straight forward!
 
So the battery at that voltage isn't able to supply the needed current for T_3.6 start - and there was a voltage drop.

Not sure what happens if this were put in setup() - for T_3.6 only - if it makes it that far?

This drops the CPU voltage and speed to 120 MHz - it messes with some peripheral used clocks { compiled for F_CPU and F_BUS at build time } and affected peripherals won't work so an idle wait is best. And wait based millis() may be skewed as well. Not sure if it breaks USB init ongoing at that time::
Code: 
setup() {
  kinetis_hsrun_disable();
  // wait for some time 
  kinetis_hsrun_enable();
  // begin normal setup
}

Another alternative might be a couple iterations of this at the start of setup():
Code: 
asm volatile( "wfi" );

Just wrote this to work with USB - but T_3.6 already started by now at full power for some 300ms:
Code: 
void setup() {
	// put your setup code here, to run once:
	kinetis_hsrun_disable();
	// wait for some time
	do 
		asm volatile( "wfi" );
	while (millis() < 1000 );
	kinetis_hsrun_enable();
	while (!Serial && millis() < 4000 );
	Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
	Serial.println(millis());
	pinMode( 13, OUTPUT );
}

void loop() {
	// put your main code here, to run repeatedly:
	digitalWrite( 13, !digitalRead( 13 ) );
	delay(1000);
}
 
Status
Not open for further replies.
Back
Top