Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: Variant of clocks_init() that allows selectively enabling PLLs (and/or clocks) #1746

Open
projectgus opened this issue Jun 25, 2024 · 2 comments
Assignees
Milestone

Comments

@projectgus
Copy link

projectgus commented Jun 25, 2024

This is a use case we found in MicroPython, as we added support for retaining the USB peripheral clock in SLEEP mode.

The mp_machine_lightsleep function selectively disables a range of clocks and PLLs, goes to SLEEP mode, and then calls pico-sdk clocks_init() on wake to restore them. Calling the init function again is useful as it saves a bunch of binary size and removes the potential for a mismatch between the clock config "on init" and "on wake".

However, we recently added support for keeping the USB peripheral clock and PLL enabled in sleep (XOSC also enabled). This works most of the time, but intermittently the USB peripheral would hang on wake as clocks_init() is re-enabling the USB PLL and presumably this can glitch the USB clock.

Our solution for now has been to copy clocks_init() as void clocks_init_optional_usb(bool init_usb). The new argument can be false if the USB PLL is already running. See micropython/micropython#15301 for more details.

However, wanted to raise it here as a request. Perhaps there is a broader use for pico-sdk API to have something like clocks_init_flags(unsigned PLL_FLAGS) function where the default clocks_init() becomes clocks_init_flags(ALL_PLL_FLAGS) (or similar).

@kilograham kilograham self-assigned this Jun 25, 2024
@kilograham kilograham added this to the 1.6.1 milestone Jun 25, 2024
@lurch
Copy link
Contributor

lurch commented Jun 25, 2024

Sounds like this might be related to #1668 and #1672 ?

@projectgus
Copy link
Author

projectgus commented Jun 25, 2024

@lurch It is, I'm sorry I should have searched first. Feel free to close in favour of either of those.

EDIT: Actually, not quite - that patch as-written doesn't meet our immediate needs as it doesn't cover PLL_USB (only PLL_SYS). But I think that approach could be extended pretty easily to also cover PLL_USB.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants