Teensy 3.2 occasionally gets stuck in bootloader mode

Mohammad · Sep 22, 2025

I have been using two different versions of T3.2 for a while. I have recently noticed occasional sticking in bootloader mode when booting up. This only occurs on T3.2 models with the MKL02 bootloader chip. There is no issue with those using the Mini54 bootloader chip.

PaulStoffregen · Sep 22, 2025

Perhaps noise is coupling to the Program signal? It very well may be more sensitive between the different chips.

I'd recommend trying a 1K or even 100 ohm resistor between Program and 3.3V, or just directly wire Program to 3.3V if you're sure you won't need to press the button.

Mohammad · Sep 23, 2025

Quick correction to my earlier post:
I previously said that the Teensy 3.2 boards without bootloader issues were using the Mini54 chip — but that was incorrect.

After closer inspection, the boards that are working fine actually use the MKL02Z32VFG4 (16QFN).

The ones that occasionally get stuck in bootloader mode are using a different chip — specifically a GD32E230F8 in a 20-pin LGA package, not the Mini54.

So just to clarify:

MKL02Z32VFG4 (16QFN) – no issues, works reliably
GD32E230F8 (LGA20) – sometimes boots into bootloader unexpectedly

Apologies for the confusion, and thanks for the help earlier. I had already tried a 10K pull-up on the Program pin, but I’m now going to test with 100Ω as suggested.

Mohammad · Sep 24, 2025

Just an update:
I tested the Teensy 3.2 boards that use the GD32E230F8 (LGA20) bootloader chip by trying:

A 100Ω pull-up from Program to 3.3V
And even directly shorting Program to 3.3V

Unfortunately, the issue persists, and the board still occasionally boots into bootloader mode on power-up.

To reiterate:
Boards with MKL02Z32VFG4 (16QFN) work perfectly with the same setup.
Only the ones with GD32E230F8 exhibit this random bootloader entry.

So it doesn't appear to be a simple pull-up sensitivity issue. Possibly something else like power-up timing, signal interpretation differences, or even internal firmware quirks in the GD32 version?

Open to any further suggestions, and thanks again for the help so far.

PaulStoffregen · Sep 25, 2025

I have not seen this behavior happen here.

Can you test on your boards using a simple program like File > Examples > 01.Basics > Blink?

If the problem happens with your program, but not with simple example programs like Blink, I hope you can understand I need a way to reproduce the problem to have even a chance of finding the cause and recommending a solution.

Mohammad · Sep 26, 2025

Thanks for your reply.
I ran a very simple test overnight using the Blink + Hibernate + Software Reboot cycle — and unfortunately, the board got stuck in bootloader mode again by morning.
This confirms that the issue is reproducible with minimal code. The board is one of the units using the GD32E230F8 (LGA20) bootloader chip.

Here’s the full sketch I used:

Code:

#include <Snooze.h>

SnoozeDigital digital;
SnoozeAlarm  alarm;
SnoozeBlock config_teensy32(digital, alarm);

#define RESTART_ADDR 0xE000ED0C
#define WRITE_RESTART(val) ((*(volatile uint32_t *)RESTART_ADDR) = (val))
void restart() {
  WRITE_RESTART(0x5FA0004);
}

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digital.pinMode(21, INPUT_PULLUP, FALLING); // pin, mode, type
}

void loop() {
  int who;

  alarm.setRtcTimer(0, 0, 10); // hour, min, sec
  who = Snooze.hibernate(config_teensy32); // returns module that woke processor

  if (who == 21) {
    digitalWrite(LED_BUILTIN, HIGH);
    delay(2000);
    digitalWrite(LED_BUILTIN, LOW);
    delay(2000);
  }

  if (who == 35) {
    digitalWrite(LED_BUILTIN, HIGH);
    delay(500);
    digitalWrite(LED_BUILTIN, LOW);
    delay(500);
  }

  restart();
}

BriComp · Sep 26, 2025

Hi Mohammad, I am sorry but I am unable to help you with your problem, but when you post code can you post it between code tags using the </> button. It preserves the code format making it easier to read. Below is your code inserted in this way.

Code:

#include <Snooze.h>

SnoozeDigital digital;
SnoozeAlarm alarm;
SnoozeBlock config_teensy32(digital, alarm);

#define RESTART_ADDR 0xE000ED0C
#define WRITE_RESTART(val) ((*(volatile uint32_t *)RESTART_ADDR) = (val))
void restart() {
    WRITE_RESTART(0x5FA0004);
}

void setup() {
    pinMode(LED_BUILTIN, OUTPUT);
    digital.pinMode(21, INPUT_PULLUP, FALLING); // pin, mode, type
}

void loop() {
    int who;

    alarm.setRtcTimer(0, 0, 10); // hour, min, sec
    who = Snooze.hibernate(config_teensy32); // returns module that woke processor

    if (who == 21) {
        digitalWrite(LED_BUILTIN, HIGH);
        delay(2000);
        digitalWrite(LED_BUILTIN, LOW);
        delay(2000);
    }

    if (who == 35) {
        digitalWrite(LED_BUILTIN, HIGH);
        delay(500);
        digitalWrite(LED_BUILTIN, LOW);
        delay(500);
    }

    restart();
}

Mohammad · Sep 26, 2025

BriComp said:

Hi Mohammad, I am sorry but I am unable to help you with your problem, but when you post code can you post it between code tags using the </> button. It preserves the code format making it easier to read. Below is your code inserted in this way.

Code:

#include <Snooze.h>

SnoozeDigital digital;
SnoozeAlarm alarm;
SnoozeBlock config_teensy32(digital, alarm);

#define RESTART_ADDR 0xE000ED0C
#define WRITE_RESTART(val) ((*(volatile uint32_t *)RESTART_ADDR) = (val))
void restart() {
    WRITE_RESTART(0x5FA0004);
}

void setup() {
    pinMode(LED_BUILTIN, OUTPUT);
    digital.pinMode(21, INPUT_PULLUP, FALLING); // pin, mode, type
}

void loop() {
    int who;

    alarm.setRtcTimer(0, 0, 10); // hour, min, sec
    who = Snooze.hibernate(config_teensy32); // returns module that woke processor

    if (who == 21) {
        digitalWrite(LED_BUILTIN, HIGH);
        delay(2000);
        digitalWrite(LED_BUILTIN, LOW);
        delay(2000);
    }

    if (who == 35) {
        digitalWrite(LED_BUILTIN, HIGH);
        delay(500);
        digitalWrite(LED_BUILTIN, LOW);
        delay(500);
    }

    restart();
}

Done!
Thanks

PaulStoffregen · Sep 28, 2025

Mohammad said:
This confirms that the issue is reproducible with minimal code.

I'm running your program from msg #6 on a Teensy 3.2 with the GD32 bootloader chip, powered by a USB cable connected a USB hub. But nothing seems to ever happen. I have not observed the LED blink, not even once so far.

Maybe more is needed that just running the program on a Teensy 3.2?

I see alarm.setRtcTimer(). Does this program require adding a 32 kHz crystal to Teensy 3.2 to be able to run? The Teensy 3.2 on my workbench isn't modified in any way, other that pins soldered for use on a breadboard it's exactly the hardware PJRC previously sold in the last Teensy 3.2 batches (when the 2022-2024 global chip shortages made the MKL02 chip unavailable).

I also see digital.pinMode(21, INPUT_PULLUP, FALLING). Will the program reproduce the problem if pin 21 has nothing connected?

This is the Teensy 3.2 on my workbench, so you can see how I'm testing. No special hardware is connected, on USB cable.

Mohammad · Sep 29, 2025

Hi Paul,
Thanks for testing and for your quick response.

Yes, you're right; in order for the SnoozeAlarm (RTC wakeup) to function correctly, the Teensy 3.2 needs a 32.768 kHz crystal soldered on. I have this crystal installed on all the boards I'm testing.

Regarding the RTC battery — I've tested both with and without a battery connected, and the result is the same either way.

The test setup is otherwise identical to yours: the board is powered via a USB cable connected to a USB hub, with no other external hardware connected.

I'm using this Snooze library:
https://github.com/duff2013/Snooze

PaulStoffregen · Sep 29, 2025

Please confirm, the code from msg #6 is supposed to reproduce the problem if I leave pin 21 disconnected and add a 32 kHz crystal?

I'm specifically asking about pin 21 before I put more time into trying to reproduce this problem.

Mohammad · Sep 29, 2025

Yes, you can leave pin 21 unconnected. You should be able to reproduce the problem with the code in msg #6. The issue might happen either after some minutes, an hour or even several hours. It is not consistent, but it will happen with GD32E230F8 bootloader chip, and never happen with MKL02Z32VFG4.

PaulStoffregen · Oct 10, 2025

Confirm, I've added the 32kHz crystal and I'm now able to reproduce this problem.

PaulStoffregen · Oct 18, 2025

Just to confirm, I am investigating this problem. But it is not easy because this program uses both low power modes and soft reset. This is the hardware currently on my workbench to attempt capturing info about why it is unintentionally entering bootloader mode.

PaulStoffregen · Oct 20, 2025

I believe I've found the problem. It is a bug in the way the new chip handles sleep mode. It escaped notice in previous testing because the bug doesn't manifest unless sleep modes are also combined with soft reboot.

I'm testing a fix now. Will contact you by email soon, as I'm not ready to release a bootloader change to the entire world where so many Teensy 3.2 boards exist, and where the very last Teensy 3.2 boards are now being shipped.

If anyone else later finds this thread and has strange sleep mode problems with these last Teensy 3.2 boards made with the GD32 chip, please contact me.

Teensy 3.2 occasionally gets stuck in bootloader mode

Mohammad

Member

Attachments

PaulStoffregen

Well-known member

Mohammad

Member

Mohammad

Member

PaulStoffregen

Well-known member

Mohammad

Member

BriComp

Well-known member

Mohammad

Member

PaulStoffregen

Well-known member

Mohammad

Member

PaulStoffregen

Well-known member

Mohammad

Member

PaulStoffregen

Well-known member

PaulStoffregen

Well-known member

PaulStoffregen

Well-known member