You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The RP2040 and 2350 board files all specify a parameter for the external crystal frequency, xoscFreq. This appears to be so that a different external crystal could be used on a particular board.
Unfortunately, the PLL configurations for the system and USB clock are hard-coded to assume a 12MHz input clock, so this setting doesn't actually work. Finding an optimal setting for the PLL is complicated, and it's probably best not to do this on the fly during the startup code.
I can think of two straightforward solutions:
Remove the xoscFreq setting. The majority of RP2040 or RP2350 designs should be expected to use a 12MHz crystal.
Add the two PLL configurations to the board (or target) configuration, so that a custom crystal frequency can be used correctly.
I think option 1 better, unless someone has a board with a nonstandard clock that they need to support. I couldn't find examples of other machines/boards that support a similar feature. If either of these sound reasonable, I'd be happy to make a pull request.
The RP2040 and 2350 board files all specify a parameter for the external crystal frequency, xoscFreq. This appears to be so that a different external crystal could be used on a particular board.
Unfortunately, the PLL configurations for the system and USB clock are hard-coded to assume a 12MHz input clock, so this setting doesn't actually work. Finding an optimal setting for the PLL is complicated, and it's probably best not to do this on the fly during the startup code.
I can think of two straightforward solutions:
I think option 1 better, unless someone has a board with a nonstandard clock that they need to support. I couldn't find examples of other machines/boards that support a similar feature. If either of these sound reasonable, I'd be happy to make a pull request.
cc @soypat @deadprogram
The text was updated successfully, but these errors were encountered: