Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: slow power supply rise time leads to Teensy 3.1 hanging

  1. #1

    slow power supply rise time leads to Teensy 3.1 hanging

    So I have an implementation where the circuit that provides 3.3v to the Teensy is an off-the-shelf part so I can't make any changes to it. The problem is that the risetime to 3.3v is almost 7 milliseconds and about 20 percent of the time the Teensy won't start (by comparison my bench supply brings it up in about 3 milliseconds and I saw one failure, plugging in USB brings it up in about 68uS and there's never been a failure).

    In every instance it will work if I power down and back up quickly. So I don't know whether the problem is in the MK20 or the Mini54. Pressing the prog button has no effect.

    So my question is 3-fold:

    1) are there any settings that we can change on either/both processors that would turn on built-in brownout detection and thus handle this problem without electrical changes.

    2) failing that since I can't get to the reset pin on the Teensy I was thinking of getting a supervisor chip and using it to drive a FET that turned on power to the chip. (this isn't really a question, more an invitation for comments on the wisdom/viability of such a solution)

    3) I am working on a custom implementation of the Teensy. It is clear now that I need to add a supervisor to this implementation - Should I have the supervisor hold the reset line on the MK20, the mini54 (which currently is un-routed) or both (not tied together obviously, but a 2-channel supervisor)?

    Thank you,

    DougM

  2. #2
    Senior Member Constantin's Avatar
    Join Date
    Nov 2012
    Location
    In the yard with a 17' Dia. Ferris Wheel
    Posts
    1,408
    Could you use a NC relay to keep the reset pin low until 3.3V power is established? Or use a transistor along the same lines? Reset is available as a pin hole on the 3.0, IIRC, and reset is accessible via a pogo pad on the underside of the 3.1.

    Or you can use a comparator chip to keep power off via a FET until the power supply is above 3.2v. I like the look of the TS9002 from SiLabs. It could also work as a supervisor for the reset line.
    Last edited by Constantin; 08-17-2015 at 09:30 PM.

  3. #3
    Thanks Constantin - I can't get to the reset pad, the boards are already assembled and the Teensys are soldered in place. But I am creating a small board with an 809 supervisor and a FET to do exactly what you are suggesting but this will require cutting traces and haywiring the board in.

    If there's a software solution or a fuse I can set that would be much better.

    Thanks,

    DougM

  4. #4
    I think I have found my solution here:

    https://forum.pjrc.com/threads/25370...Watchdog-Timer

    Thanks all!

    DougM

  5. #5
    Junior Member
    Join Date
    Jan 2017
    Posts
    6
    @DougM - I am having the exact same problem as you describe (Teensy 3.2).
    Would you be able to provide some more details on how you solved it by changing Watchdog settings - if possible, including a code snippet that worked for you.
    I have looked at the page you linked to but I'm afraid it's not obvious to me.
    Many thanks.

  6. #6
    Ok, it's been a while but the last code I wrote that had the watchdog all the defines had been added to the library.

    In my header I have:

    IntervalTimer wdTimer;

    in my setup I have:

    wdTimer.begin(KickDog, 500000); // kick the dog every 500msec
    and
    printResetType();

    kickdog looks like this:

    void KickDog() {
    Serial.println("Kicking the dog!");
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
    noInterrupts();
    WDOG_REFRESH = 0xA602;
    WDOG_REFRESH = 0xB480;
    interrupts();
    }

    PrintResetType looks like this (note that it writes to the TFT and not the serial):

    void printResetType()
    {
    tft.setCursor(5,220);
    if (RCM_SRS1 & RCM_SRS1_SACKERR) tft.print("Stop Mode Acknowledge Error Reset");
    if (RCM_SRS1 & RCM_SRS1_MDM_AP) tft.print("MDM-AP Reset");
    if (RCM_SRS1 & RCM_SRS1_SW) tft.print("Software Reset");
    if (RCM_SRS1 & RCM_SRS1_LOCKUP) tft.print("Core Lockup Event Reset");
    if (RCM_SRS0 & RCM_SRS0_POR) tft.print("Power-on Reset");
    if (RCM_SRS0 & RCM_SRS0_PIN) tft.print("External Pin Reset");
    if (RCM_SRS0 & RCM_SRS0_WDOG) tft.print("Watchdog(COP) Reset");
    if (RCM_SRS0 & RCM_SRS0_LOC) tft.print("Loss of External Clock Reset");
    if (RCM_SRS0 & RCM_SRS0_LOL) tft.print("Loss of Lock in PLL Reset");
    if (RCM_SRS0 & RCM_SRS0_LVD) tft.print("Low-voltage Detect Reset");
    }

    Good luck!

  7. #7
    Junior Member
    Join Date
    Jan 2017
    Posts
    6
    Thanks for the code. I got the watchdog working however unfortunately it does not prevent my Teensy 3.2s hanging.

    The teensies are powered from a USB hub which is in turn powered by a large DC/DC converter so I think the 5V rises slowly - need to scope it later.

    Having read around the forum further, I wondered if the Teensy may require a longer delay before usb_init() as suggested by Paul in post #32 here:
    https://forum.pjrc.com/threads/24304...yduino()/page2

    Would be interested to know if the Bootloader mcu can hang in reset if the startup rise time of its power supply is too low, and if so, if that could be holding my Teensy in bootload mode?

  8. #8
    Are you sure the hang isn't related to other parts of your code? Have you tried running nothing but blink and watchdog? I would see if there ins't some while loop that it's getting caught in...

  9. #9
    Junior Member
    Join Date
    Nov 2017
    Posts
    2
    Cutting traces for fet is important. So about fet basics it is important to make EMC right.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •