Add startup_delay_multiplier parameter to xosc initialization

[jannic]

This works the same way as PICO_XOSC_STARTUP_DELAY_MULTIPLIER in the Pico SDK

Closes #745

[laenzlinger]

Thanks @jannic. I will test it tonight.

[laenzlinger]

@jannic I have successfully tested the change in principle. (when multiplying startup_delay by 10, the RP2040 on my custom board boots reliably)

I am still pretty new to rust, and I am not sure how I could use the change in my code.

IIUC, i would have to copy and change init_clocks_and_plls() and setup_pll_blocking(), since I am using this currently in my application.

Wouldn't it make sense to at least also pass startup_delay_multiplier also to setup_pll_blocking()? That would allow me to reuse more code of the lib.

[jannic]

Yes, the patch was meant to be sufficient to make your use case possible. But it's definitely not yet tuned for usability.
Thanks for testing it!
I'm curious how commonly this setting would be needed. Do you know why it's necessary for your board? Is it just the type of oscillator you are using?

[laenzlinger]

Do you know why it's necessary for your board?

Thats a very good question, for me its difficult to say.

But lets try to base on on some facts:

https://forums.raspberrypi.com/search.php?keywords=PICO_XOSC_STARTUP_DELAY_MULTIPLIER returns 39 matches.

• Its not just me that is affected.
• I used the exact same components described in the official hardware design guidelines https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf (Chapter 2.3). Thats why I think, also other people will run in future into the same issues.

Why did if affect me?

I have to experiment a bit further.

• It might be that due to my simple (but cost effective) 2 layer design, the parasitic capacitance of the circuit is different than in the reference design
• It might be just component outliers. So far I only built 2 prototypes and one of them was affected. Other forum posts mentioned 20% of non working samples.

However, for future versions of my design, I will probably switch to some other components, because I find the XTAL physically too large. I might choose some components that are widely used on Pico Board or Adafruit boards (If that information is publicly available)

My recommendation is to allow the user to tune the value. As in my case the effort of fixing the hardware design (or fixing individual samples) would be much higher than changing it via software. Even if it was just outlier, for my application, I would prefer slower startup time than less stable operation. For my application, the addition 10ms of startup time are really irrelevant.

[jannic]

Yes, 10ms shouldn't be an issue in most cases. I wonder if we should even use a higher multiplier by default and provide a separate function to initialize the oscillator with a configurable delay.

[laenzlinger]

That sounds like a perfect plan for me

[laenzlinger]

LGTM