This command will let you find a few areas where the API has been used:
grep -r -e 'pm_[un]*block' -e pm_set
In general I think the idea is to number the power modes such that you:
* Start by giving your lowest power mode 0
* Then find the next lowest power mode that supports features that are
a superset of the features supported by 0, and make that mode 1
* Repeat until you run out of power modes.
You then write a function pm_set in cpu/*/periph/pm.c that implements
switching the power modes. And also you set up anything that can't run
in a certain power mode to pm_block that mode, and then to pm_unblock
when it stops running. I think the kernel then handles the rest.
There may be some details I missed, because I am not super-familiar
with the system, but this should give you a good start.
Welcome to RIOT!
There is a pull request to integrate stop modes for the Kinetis CPUs 1. There’s no VLPR or VLPW yet, but STOP, VLPS, and LLS are working. It does need a rebase though.
We could use some help reviewing this and some other related Kinetis pull requests 2, 3, 4 if you would like to help with this. Feel free to open new PRs for any other improvements you may have.
My guess is that your board uses xtimer with the PIT timer hardware, try using the LPTMR instead. See the frdm-kw41z configuration for an example config (board.h, periph_conf.h). I think Mulle has a config example as well but it is disabled by default.
You might find the timer refactoring PRs helpful 1, 2, 3 (any help with testing and reviewing is welcome!)
You might also have the UART RX blocking power modes if you don’t configure the llwu pin in the UART config. Clocking mode will affect the reliability of the UART in low power mode, some clock modes take too long to recover from sleep mode so you will miss the first few characters on RX. Use FEI if unsure.
Thanks for the offer of helping! Could you write a short review on
each of the PRs that you have used/tested to let others know what the
state is and whether anything is not working as intended?
A review from a non-maintainer can not be used to approve and merge
PRs, but it does give an indication to the people with the proper
access that a PR is ready or if it needs more work.
#7897 is still pending. If you would like to help you could run some
tests on your board with that PR and report your results. There is
still one issue reported in the PR discussion thread which I have not
looked into yet related to the phytec board and UART in low power
Can you confirm me Kinetis Low Power Modes are fully supported in Riot/master ?
Not yet, #7897 is still awaiting review and testing
Should I switch my board from PIT to LPTMR to enable these low power modes ?
Unless you have a reason for requiring better than 30.5 µs precision
on xtimer, I don't see any reason for not using LPTMR as XTIMER_DEV.
I haven’t found a way to get the debugger to connect reliably with low power modes without manual intervention.
If you hold the reset button on the development board when you do a make flash until you get to the point where it has identified the CPU it should work. Release the reset and then the flashing should complete successfully. I haven’t tested on the kw2xd, but it works on at least the k22f and the kw41z.
Hope this helps.