8-blink instability on Teensyduino 1.60 depending on clock source

[Cyphage]

Hello,

I'm investigating a stability issue with a Teensy 4.1 used on a MicroDexed baseboard. The system is configured to run at 132.92 MHz from PLL3 PFD0 (664.62 MHz).

CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_OFF);
CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_FLEXSPI2_PODF_MASK | CCM_CBCMR_FLEXSPI2_CLK_SEL_MASK))
  | CCM_CBCMR_FLEXSPI2_PODF(4) | CCM_CBCMR_FLEXSPI2_CLK_SEL(2);
CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);

Under Teensyduino 1.59, it operates fine. However, when compiled with Teensyduino 1.60, the board has audio stuttering and UI glitches every 4 - 5 seconds and frequently enters the 8-blink error state when connected to a laptop over USB. The issue appears tied to USB operation, as the board runs without issue powered from a wall supply.

I tested multiple USB cables and ports and disabled USB power management on the laptop. Changing the clock source to PLL2 PFD2 (396 MHz -> 132.00 MHz) eliminates the issue entirely under Teensyduino 1.60.

CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_OFF);
CCM_CBCMR = 0x55AE8004; // PLL2 PFD2 ÷3 = 132 MHz
CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);

Just hoping for clarification on whether this pattern is consistent with known changes in 1.60

Thanks!
Mike

 

[jmarsh]

CCM_CCGR7 |= CCM_CCGR7_FLEXSPI2(CCM_CCGR_OFF);

I don't think this is doing what you want it to.

 

[PaulStoffregen]

The system is configured to run at 132.92 MHz from PLL3 PFD0 (664.62 MHz).

PLL3 PFD0 default is 720 MHz.

 

[Cyphage]

I don't think this is doing what you want it to.

I will try

CCM_CCGR7 &= ~CCM_CCGR7_FLEXSPI2(CCM_CCGR_ON);

Hope that wasn't part of the issue...

PLL3 PFD0 default is 720 MHz.

I measured FlexSPI2 at 132.9 MHz, so PLL3 PFD0 must have been initialized earlier to 664 MHz, though I can’t find where in the code this happens. And the original comment says 528/5 = 132 MHz, which doesn’t match. Does 1.60 initialize PLLs differently?

 

[jmarsh]

Is FLEXSPI2_CLK_SEL(2) PFD1 rather than PFD0?

1.60 initializes FLEXSPI2 at a slightly higher multiplier than before. So it may just be more important to gate it properly before modifying.