Add support for configuring XOSC FREQ_RANGE #3152

2026-08-21T04:56:23-05:00

will-v-pi commented

2026-08-21 04:56:23 -05:00

(Migrated from github.com)

Add PICO_XOSC_FREQ_RANGE_MAX config for non-RP2040 chips - defaults to XOSC_HZ / 1000000, but can be configured higher (e.g. to select the 40-100MHz range for a 50MHz crystal)

RP2040 only has one range, so this config is not defined for RP2040, as CMOS clock inputs >15MHz are still supported despite being out of the XOSC FREQ_RANGE value

Fixes #3074

Add PICO_XOSC_FREQ_RANGE_MAX config for non-RP2040 chips - defaults to XOSC_HZ / 1000000, but can be configured higher (e.g. to select the 40-100MHz range for a 50MHz crystal) RP2040 only has one range, so this config is not defined for RP2040, as CMOS clock inputs >15MHz are still supported despite being out of the XOSC FREQ_RANGE value Fixes #3074

lurch (Migrated from github.com) reviewed

2026-08-21 08:14:33 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

This might be a stupid question, but why does this allow PICO_XOSC_FREQ_RANGE_MAX values up to 100 MHz, when the check on line 16 of this same file caps XOSC_HZ at 50 MHz?

This might be a stupid question, but why does this allow `PICO_XOSC_FREQ_RANGE_MAX` values up to 100 MHz, when the check on line 16 of this same file caps `XOSC_HZ` at 50 MHz?

lurch commented

2026-08-21 08:18:21 -05:00

(Migrated from github.com)

It's very slightly OffTopic, but maybe this PR would also be a good place to edit src/rp2040/hardware_regs/include/hardware/platform_defs.h and src/rp2350/hardware_regs/include/hardware/platform_defs.h to add min=1000000, max=50000000, to the PICO_CONFIG: XOSC_HZ lines? 🙂

It's _very slightly_ OffTopic, but maybe this PR would also be a good place to edit `src/rp2040/hardware_regs/include/hardware/platform_defs.h` and `src/rp2350/hardware_regs/include/hardware/platform_defs.h` to add `min=1000000, max=50000000,` to the `PICO_CONFIG: XOSC_HZ` lines? :slightly_smiling_face:

lurch (Migrated from github.com) reviewed

2026-08-21 08:21:02 -05:00

src/rp2_common/hardware_xosc/include/hardware/xosc.h

					
				@ -13,3 +15,4 @@

				// Allow lengthening startup delay to accommodate slow-starting oscillators

#define PICO_XOSC_FREQ_RANGE_MAX (XOSC_HZ / MHZ)

?

```suggestion #define PICO_XOSC_FREQ_RANGE_MAX (XOSC_HZ / MHZ) ``` ?

will-v-pi (Migrated from github.com) reviewed

2026-08-21 09:53:59 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

Because the ranges are:

1-15
10-30
25-60
40-100

so you need to be able to specify values above 50 to pick the final range, if you want that range instead of the 25-60 one

Because the ranges are: - 1-15 - 10-30 - 25-60 - 40-100 so you need to be able to specify values above 50 to pick the final range, if you want that range instead of the 25-60 one

will-v-pi (Migrated from github.com) reviewed

2026-08-21 09:54:18 -05:00

src/rp2_common/hardware_xosc/include/hardware/xosc.h

					
				@ -13,3 +15,4 @@

				// Allow lengthening startup delay to accommodate slow-starting oscillators

Yes, this already links hardware_clocks, so I can include hardware/clocks.h and use MHZ

Yes, this already links `hardware_clocks`, so I can include `hardware/clocks.h` and use `MHZ`

will-v-pi commented

2026-08-21 10:01:31 -05:00

(Migrated from github.com)

It's very slightly OffTopic, but maybe this PR would also be a good place to edit src/rp2040/hardware_regs/include/hardware/platform_defs.h and src/rp2350/hardware_regs/include/hardware/platform_defs.h to add min=1000000, max=50000000, to the PICO_CONFIG: XOSC_HZ lines? 🙂

Thanks, added - I didn't add a note on RP2040 that values above 15MHz are only supported when using CMOS clock inputs, as that is very much a board design thing rather than an SDK thing

> It's _very slightly_ OffTopic, but maybe this PR would also be a good place to edit `src/rp2040/hardware_regs/include/hardware/platform_defs.h` and `src/rp2350/hardware_regs/include/hardware/platform_defs.h` to add `min=1000000, max=50000000,` to the `PICO_CONFIG: XOSC_HZ` lines? 🙂 Thanks, added - I didn't add a note on RP2040 that values above 15MHz are only supported when using CMOS clock inputs, as that is very much a board design thing rather than an SDK thing

👍 1

lurch (Migrated from github.com) reviewed

2026-08-21 10:51:33 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

Okay, next stupid question: If using a 50 MHz frequency, is there any reason for choosing a range of 40-100 vs. choosing a range of 25-60?

EDIT: The reason I'm asking, is because I wonder if this could instead be calculated from the existing XOSC_HZ define, rather than requiring the addition of a new PICO_XOSC_FREQ_RANGE_MAX define?

EDIT2: Although if we do need both a XOSC_HZ and PICO_XOSC_FREQ_RANGE_MAX, maybe there could / should also be a check that XOSC_HZ <= (PICO_XOSC_FREQ_RANGE_MAX * MHZ) ? 🤔

Okay, next stupid question: If using a 50 MHz frequency, is there any reason for choosing a range of 40-100 vs. choosing a range of 25-60? EDIT: The reason I'm asking, is because I wonder if this could instead be calculated from the existing `XOSC_HZ` define, rather than requiring the addition of a new `PICO_XOSC_FREQ_RANGE_MAX` define? EDIT2: Although if we _do_ need both a `XOSC_HZ` and `PICO_XOSC_FREQ_RANGE_MAX`, maybe there could / should also be a check that `XOSC_HZ <= (PICO_XOSC_FREQ_RANGE_MAX * MHZ)` ? :thinking:

will-v-pi (Migrated from github.com) reviewed

2026-08-21 10:55:12 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

I'm not sure, you would have to ask the ASIC team (@davidb990 might know?)

davidb990 (Migrated from github.com) reviewed

2026-08-21 11:37:12 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

I can't spot anything in the datasheet to say you should pick one range over the other.

FWIW, the frequency ranges are used as a proxy for drive strength, so the choice ought to depend on how difficult the crystal is to drive - there could be a case where one 50 MHz crystal is better served by the 40-100 range, and another is better served by the 25-60 range (so perhaps leaving the choice up to the user to select based on their implementation is marginally preferable?)

I can't spot anything in the datasheet to say you should pick one range over the other. FWIW, the frequency ranges are used as a proxy for drive strength, so the choice ought to depend on how difficult the crystal is to drive - there could be a case where one 50 MHz crystal is better served by the 40-100 range, and another is better served by the 25-60 range (so perhaps leaving the choice up to the user to select based on their implementation is marginally preferable?)

lurch (Migrated from github.com) reviewed

2026-08-21 11:46:02 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

there could be a case where one 50 MHz crystal is better served by the 40-100 range, and another is better served by the 25-60 range (so perhaps leaving the choice up to the user to select based on their implementation is marginally preferable?)

Huh, fair enough 👍

But that still leaves my EDIT2 question above un-answered 😉

> there could be a case where one 50 MHz crystal is better served by the 40-100 range, and another is better served by the 25-60 range (so perhaps leaving the choice up to the user to select based on their implementation is marginally preferable?) Huh, fair enough :+1: But that still leaves my EDIT2 question above un-answered :wink:

will-v-pi (Migrated from github.com) reviewed

2026-08-21 12:31:34 -05:00

src/rp2_common/hardware_xosc/xosc.c

					
				@ -32,0 +37,4 @@

				    xosc_hw->ctrl = XOSC_CTRL_FREQ_RANGE_VALUE_40_100MHZ;

				#else

				    #error PICO_XOSC_FREQ_RANGE_MAX is too large, maximum is 100

				#endif

I think it’s fine to not check it, because if you’re explicitly setting it lower than your XOSC_HZ you may have a reason (eg wanting lower drive strengths because your crystal works with them, or you’re using a CMOS clock input and want a lower setting, or something)