Increase default value of PICO_XOSC_STARTUP_DELAY_MULTIPLIER #2234

New issue

Closed

opened 2025-02-04 10:15:16 -06:00 by kilograham · 7 comments

kilograham commented

2025-02-04 10:15:16 -06:00

(Migrated from github.com)

change this by default to 6

Wren6991 commented

2025-02-04 10:22:29 -06:00

(Migrated from github.com)

Reasoning is:

Quite a few third-party boards have increased this value from its default, suggesting that it is not a good default (https://github.com/search?q=repo%3Araspberrypi%2Fpico-sdk%20PICO_XOSC_STARTUP_DELAY_MULTIPLIER&type=code)
Looking at crystal startup on a scope shows that the recommended AEL crystal with series resistor takes around 6 ms to reach full swing (measured by @P33M) so we have been living dangerously

The minimal change is just to bump the default provided here: github.com/raspberrypi/pico-sdk@95ea6acad1/src/rp2_common/hardware_xosc/include/hardware/xosc.h (L18)

To avoid impact on boot time, we could also pull the XOSC enable earlier in boot (e.g. in crt0, before .data and .bss init) and then just poll during xosc_init(). However this will be an incompatible change for those who are overriding the weak clocks_init() symbol without setting PICO_RUNTIME_SKIP_INIT_CLOCKS=1 etc.

Note PICO_XOSC_STARTUP_DELAY_MULTIPLIER is poorly named and is really just the startup delay in milliseconds.

Reasoning is: * Quite a few third-party boards have increased this value from its default, suggesting that it is not a *good* default (https://github.com/search?q=repo%3Araspberrypi%2Fpico-sdk%20PICO_XOSC_STARTUP_DELAY_MULTIPLIER&type=code) * Looking at crystal startup on a scope shows that the recommended AEL crystal with series resistor takes around 6 ms to reach full swing (measured by @P33M) so we have been living dangerously The minimal change is just to bump the default provided here: https://github.com/raspberrypi/pico-sdk/blob/95ea6acad131124694cda1c162c52cd30e0aece0/src/rp2_common/hardware_xosc/include/hardware/xosc.h#L18 To avoid impact on boot time, we could also pull the XOSC enable earlier in boot (e.g. in crt0, before `.data` and `.bss` init) and then just poll during `xosc_init()`. However this will be an incompatible change for those who are overriding the weak `clocks_init()` symbol without setting `PICO_RUNTIME_SKIP_INIT_CLOCKS=1` etc. Note `PICO_XOSC_STARTUP_DELAY_MULTIPLIER` is poorly named and is really just the startup delay in milliseconds.

dhalbert commented

2025-02-04 11:53:34 -06:00

(Migrated from github.com)

The default of 6 would still be too low for us, so we'll keep it at 64 for our boards, based on our empirical testing from that time.

Renaming is fine with us, of course. When I came up with the name it didn't occur to me (or the reviewers) that it was just milliseconds.

I was the instigator of this long ago via #457. We (Adafruit) had chosen slightly different xosc parts and were having longer startup problems on a few boards. We didn't know how you were testing the Pico boards yourself and whether you were discarding some with longer delays as "bad". So this could improve your yield 😄 . The default of 6 would still be too low for us, so we'll keep it at 64 for our boards, based on our empirical testing from that time. Renaming is fine with us, of course. When I came up with the name it didn't occur to me (or the reviewers) that it was just milliseconds.

P33M commented

2025-02-04 12:31:26 -06:00

(Migrated from github.com)

This is a board-dependent parameter and should be measured with appropriate test equipment. It is a function of the selected crystal, XOSC drive strength (but due to a hardware bug on RP2040, only the lowest one works), parallel loading capacitance, and series resistor. For information, the XOSC ripple counter will begin to count up very early in the crystal ramp - XIN will produce seemingly valid clock pulses with a tiny swing.

Ramp times for Pico and Pico 2 are basically identical. Your mileage will vary.

kilograham commented

2025-02-05 11:08:22 -06:00

(Migrated from github.com)