I've been working on a very frustrating situation with sensors I have in the field and bench based on T3.2. 15 - 20% of my units exhibit this issue. Quantity is about 200 units.
My host board provides 5V and 3.3V to components on the board. T3.2 is running off the 3.3V side. The main thing running off the 5V side is a Digi XBee cellular AT&T 4LTE Cat 1. This device is a power hog and I suspect is at times drawing so much power that it is forcing the T3.2 into a brownout condition. There is a rectifying circuit taking 12-24 VDC to VAC prior to going through 1.5A Murata voltage regulators to get to 3.3V and 5V. So ultimately they do share the same power input which is why I have a problem when the XBee is running at 5V. Sensors in the field and on my bench are lights out...no activity that I can detect on the XBee or Teensy.
Voltage tests on the board during this condition show normal voltages at the 5V and 3.3V locations, including the Teensy and XBee. Since the Teensy controls the XBee power, I've been able to show that the enable line to the XBee has gone low and so it's not running either. Nothing on the board appears to be running even though voltage levels are normal.
A power reboot fixes the problem for an undertermined amount of time. Some units only last minutes before a similar problem occurs. Some "identical" units have run months before a similar problem occurs.
I run through all the watchdog examples out there on the forum as well as some blogs. The basic watchdog is not working, as in this does not appear to be a firmware problem. No reset occurs before it's just lights out which is a major reason I think this could be an unrecovered brownout problem.
After seeing the watchdog fail, I turned to the lower level Freescale research to understand their brownout detection capability. For those interested, you can find information about this on the Freescale doc hosted on PJRC: https://www.pjrc.com/teensy/K20P64M50SF0RM.pdf Go to section 15.5.1 page 283.
Thinking that I just needed to set some bits for the register at 4007_D000h, I first pulled the runtime values to see what they were and found that they were already set how I would expect. LVDRE, bit 4, is 1 (force and MCU reset). LVDV, bit 0,1, is set to 00 which is (Low Trip Point Selected). I made no changes as it seemed this was set to do what I would have though it should do.
Having exhausted my known sources of watchdog and brownout detection, I am turning to try some voltage detection devices as well as external watchdog chips to help under the assumption I could pull the RST pin low and reset the Teensy.
To test this prior to dead-bugging some chips, I soldered a jumper wire onto the RST pin underneath and just let it dangle. In normal runtime, if I touch off the pin to ground, the Teensy 3.2 reboots, as expected. With it crashed, I touched off the RST jumper wire onto a ground pin. No joy.
During the crash state, I measure RST pin at 0mV (or very close to 0). It's sitting on GND even though VCC is 3.3V. If I touch RST to 3.3V, the Teensy starts up again, but something is not right because as soon as I release RST from 3.3V, it goes down again. Perhaps I don't understand how to properly reboot the 3.2 through RST pin, but my understanding was that simply grounding it and releasing it would work. Obviously if it's already grounded, that doesn't do anything.
So if I can't ground RST to get a proper reboot because it's already grounded, are there other options to bounce this thing? What have I missed? I will be stiffening up my power supply by adding some additional fast capacitance on both 5V and 3.3V sides, but need to find a solution for the field that I can retrofit in the meantime to at least reboot and go again without me being there.
Thanks for any insights you may have.
My host board provides 5V and 3.3V to components on the board. T3.2 is running off the 3.3V side. The main thing running off the 5V side is a Digi XBee cellular AT&T 4LTE Cat 1. This device is a power hog and I suspect is at times drawing so much power that it is forcing the T3.2 into a brownout condition. There is a rectifying circuit taking 12-24 VDC to VAC prior to going through 1.5A Murata voltage regulators to get to 3.3V and 5V. So ultimately they do share the same power input which is why I have a problem when the XBee is running at 5V. Sensors in the field and on my bench are lights out...no activity that I can detect on the XBee or Teensy.
Voltage tests on the board during this condition show normal voltages at the 5V and 3.3V locations, including the Teensy and XBee. Since the Teensy controls the XBee power, I've been able to show that the enable line to the XBee has gone low and so it's not running either. Nothing on the board appears to be running even though voltage levels are normal.
A power reboot fixes the problem for an undertermined amount of time. Some units only last minutes before a similar problem occurs. Some "identical" units have run months before a similar problem occurs.
I run through all the watchdog examples out there on the forum as well as some blogs. The basic watchdog is not working, as in this does not appear to be a firmware problem. No reset occurs before it's just lights out which is a major reason I think this could be an unrecovered brownout problem.
After seeing the watchdog fail, I turned to the lower level Freescale research to understand their brownout detection capability. For those interested, you can find information about this on the Freescale doc hosted on PJRC: https://www.pjrc.com/teensy/K20P64M50SF0RM.pdf Go to section 15.5.1 page 283.
Thinking that I just needed to set some bits for the register at 4007_D000h, I first pulled the runtime values to see what they were and found that they were already set how I would expect. LVDRE, bit 4, is 1 (force and MCU reset). LVDV, bit 0,1, is set to 00 which is (Low Trip Point Selected). I made no changes as it seemed this was set to do what I would have though it should do.
Having exhausted my known sources of watchdog and brownout detection, I am turning to try some voltage detection devices as well as external watchdog chips to help under the assumption I could pull the RST pin low and reset the Teensy.
To test this prior to dead-bugging some chips, I soldered a jumper wire onto the RST pin underneath and just let it dangle. In normal runtime, if I touch off the pin to ground, the Teensy 3.2 reboots, as expected. With it crashed, I touched off the RST jumper wire onto a ground pin. No joy.
During the crash state, I measure RST pin at 0mV (or very close to 0). It's sitting on GND even though VCC is 3.3V. If I touch RST to 3.3V, the Teensy starts up again, but something is not right because as soon as I release RST from 3.3V, it goes down again. Perhaps I don't understand how to properly reboot the 3.2 through RST pin, but my understanding was that simply grounding it and releasing it would work. Obviously if it's already grounded, that doesn't do anything.
So if I can't ground RST to get a proper reboot because it's already grounded, are there other options to bounce this thing? What have I missed? I will be stiffening up my power supply by adding some additional fast capacitance on both 5V and 3.3V sides, but need to find a solution for the field that I can retrofit in the meantime to at least reboot and go again without me being there.
Thanks for any insights you may have.