Skip to content

ports/stm32/powerctrl.c Enable user EWUP control #6494

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

Closed
wants to merge 1 commit into from

Conversation

peterhinch
Copy link
Contributor

The Pyboard 1.x supports standby wakeup via X1 or X18, as implemented in this repo.

Unfortunately this line prevents this from working on the D series. This PR remedies this by saving and restoring any EWUP flags set by the user. Wakeup can now be performed on the D series via pins X1 and X18.

@irsla
Copy link

irsla commented Sep 28, 2020

Ok now we have a duplicate for this issue, which is good, it means that it will be solved one way or another.

So now we need to discuss the solutions.

Solution 1 (time based): PR 6482:

  • provide full control over X1 and X18 wake up pins in the machine/pyb module in an "easy way"
    - full control:
    - set wake up pin
    - set trigger on falling/raising wake up
    - get the reset_cause
    Solution 2 (time based): PR 6494 (this one)
  • handle full control over X1 and X18 to the user
    - full control:
    - set wake up pin in python
    - set trigger on falling/raising wake up in python
    - get the reset_cause in python

Both solution have advantages and drawbacks.

Drawbacks:
Solution 1:
a lot of C code as we will need to break the calling of machine_deepsleep from pyb_standby in order to control the pins and will have to duplicate the reset_cause and have a fall-through machine_reset_cause if pyb_reset_cause is not X1/X18

Solution 2:
the complexity is moved to the user/developer

How can we have this discussion ?

Duplicate: #6482

@peterhinch
Copy link
Contributor Author

This PR is a bugfix. It ensures that the Pyboard D behaves similarly to Pyboard 1.x. There is no conflict with alternative micropower solutions.

@peterhinch
Copy link
Contributor Author

@dpgeorge Any thoughts on this? It does seem unfortunate to lose functionality which has been available for years on Pyboard 1.x. Is there a reason for this?

@jimmo
Copy link
Member

jimmo commented Nov 3, 2020

@peterhinch Sorry for the possibly dumb question but I'm not super familiar with STM32 power management. Is there a hidden interaction that I don't understand -- why is this way of solving it necessary? i.e. why doesn't removing the // disable wake-up flags line achieve the same thing? Is there an AN or RM we can link to that explains this?

@peterhinch
Copy link
Contributor Author

It would achieve the same thing. I gather Damien has identified a hardware issue whereby the wakeup sources must be disabled while clearing the global flag. This code comment indicates that this is the case. I therefore used this approach, which works in my testing.

@peterhinch
Copy link
Contributor Author

There are forum users asking about this. Is there a reason for not implementing this simple fix?

@dpgeorge
Copy link
Member

Sorry, this PR got really lost.

I agree with the fix, it is needed. ST examples do it this way (disable wake-up sources, clear wake-up flag, re-enable wake-up sources, enter stand-by mode).

Tested and merged in 0facd89

Thank you very much @peterhinch !

@dpgeorge dpgeorge closed this Mar 10, 2021
@peterhinch peterhinch deleted the patch-3 branch March 10, 2021 16:00
tannewt pushed a commit to tannewt/circuitpython that referenced this pull request Jun 27, 2022
include python executable path in the idf key
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants