Teensy 4.1 doesn't boot since 8.0.0 beta 1

[RetiredWizard]

CircuitPython version

adafruit-circuitpython-teensy41-en_US-8.0.0-beta.1.hex 
and all newer builds

Code/REPL

Not a Code issue

Behavior

After flashing CircuitPython and rebooting the board, no serial port is available and no USB drive is mounted.

Description

I've tried compiling a DEBUG=1 build and creating a UART debug console to see if there are any boot loop messages being displayed by changing mpconfigboard.h as follows

// #define DEFAULT_UART_BUS_RX (&pin_GPIO_AD_B0_03)
// #define DEFAULT_UART_BUS_TX (&pin_GPIO_AD_B0_02)

#define DEFAULT_UART_BUS_RX (&pin_GPIO_B1_01)
#define DEFAULT_UART_BUS_TX (&pin_GPIO_B1_00)

#define CIRCUITPY_CONSOLE_UART_RX (&pin_GPIO_AD_B0_03)
#define CIRCUITPY_CONSOLE_UART_TX (&pin_GPIO_AD_B0_02)

but I haven't seen any output on the RX/TX pins.

Additional information

adafruit-circuitpython-teensy41-en_US-7.3.3.hex flashes and runs fine...

[RetiredWizard]

I found an old 8.0.0 alpha.1 teensy 4.1 build that still works:

Adafruit CircuitPython 8.0.0-alpha.1-30-g8814ee03f-dirty on 2022-07-03; Teensy 4.1 with IMXRT1062DVJ6A

[tannewt]

@RetiredWizard is that the last version that works? aka is the next commit the one that broke it?

[RetiredWizard]

From the S3 archives the date/version of the last build that worked was 2022-08-29/7.3.3,

Everything more recent that I've tested has failed and everything earlier works. 8.0.0 Beta 0 is the highest version number created before that date and does work.

The next build after 7.3.3 and the first to not work was built on 22-10-01/8.0.0 Beta 1.

[RetiredWizard]

The Teensy 4.1 board apparently has a FLASHing indicator LED. It lights up when you put the board in program mode and while you're flashing but that's the only time I've seen it lit.

When I have one of the faulty CP builds installed, I've noticed a sequence of (I believe) 7 quick flashes of this LED. Sometimes the sequence happens immediately following the Flash program operation but not always. I've also seen it occur at seemingly random times.

[RetiredWizard]

I found the change that broke the Teensy41 boot with 8.0.0.Beta.1.

In main.c, if you move the board_init() call to where it was in 8.0.0.Beta.0 (before the reset_port call) the Teensy41 build works. I tested the change out on 8.0.0.Beta.5 and it results in a working Teensy41 boot.

I'm sure this isn't the fix but hopefully it moves us closer to one.

[RetiredWizard]

reset_port() calls reset_all_pins() which appears to reset any pin that hasn't been set in never_reset_pins but board_init() is the routine that seems to set the never_reset_pins array.

Perhaps we need to separate out the pin configuration from other board_init functions, maybe create a new function in board.c called something like pin_config which could be called prior to reset_port and allow the display initialization functions in board_init to happen after reset_port?

While trying to see how some of the other ports handled this, I noticed that espressif/supervisor/port.c was flagging pins as never_reset which led me to the following comment in mimxrt10xx/supervisor/port.c

// Note that `reset_port` CANNOT GO HERE, unlike other ports, because `board_init` hasn't been
// run yet, which uses `never_reset` to protect critical pins from being reset by  `reset_port`.

[tannewt]

Thanks for figuring this out! I think copying the espressif port is best. It has both port level pins that it doesn't reset and has a weak function that the board can implement to reset itself.

https://github.com/adafruit/circuitpython/blob/main/ports/espressif/common-hal/microcontroller/Pin.c#L133

[RetiredWizard]

I've done a little poking around the espressif port and it looks like a pretty significant rework of the mimxrt10xx port is required. I don't think I understand how all the modules interact well enough to take this one on 😃.

[RetiredWizard]

Thanks Dan! I clearly don't have a grasp on how the port modules work because I didn't see this fix being anything like it turned out 😄