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

Rework CMAC sleep calculations #3049

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

andrzej-kaczmarek
Copy link
Contributor

No description provided.

We should calculate XTALRDY value assuming worst case which is the max
possible RC32M frequency (32.6 MHz). If the actual frequency of RC32M
is lower than 32.6 MHz, it will take longer time than set to mark xtal
as settled which is still ok since we don't want xtal to be "settled"
to early.
This adds helper to calculate number of lpclk ticks required for wakeup,
i.e. wakeup fsm + xtal32m settle time. This can be then used to adjust
sleep time.
In case RCX is enabled, we call lpclk enable from sysinit instead of
system init.
@andrzej-kaczmarek andrzej-kaczmarek force-pushed the cmac-sleep-fix branch 2 times, most recently from 82e5794 to 1c2f1e5 Compare August 9, 2023 00:14
Sleep time calculation on CMAC assumed incorrectly that wakeup fsm uses
lpclk but in fact RC32K is used so we need to take it into account. To
make things easier to handle on CMAC side we will calculate wakeup time
on M33 side and pass it to CMAC instead of XTAL32M settle time. This way
we don't really need to care about how wakeup fsm is configured.

It's now expected that M33 will take care of RC32K calibration and will
calculate proper wakeup time based on wakeup fsm settings and XTAL32M
settle time, and then notify CMAC on any change so we can recalculate
our min sleep time.
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

Successfully merging this pull request may close these issues.

1 participant