Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This closes #28.
This PR exposes
remote_wakeup
method that can be used to implement remote wakeup from USB suspend (e.g. for devices like keyboards/mice). I have tested it on STM32F072 device.To perform remote wakeup, device must set
CNTR.RESUME
bit for 1-15 ms, so in order to properly implement it we must have means to measure time until clearing this bit. TheUsbBus
does not know current time, so it cannot do the countdown. While in generalUsbBus
could enable and use SOF interrupt (1 kHz) to count time for some needs, during suspend USB host doesn't send SOF (this is actually the indicator of USB suspend), so the whole countdown must be implemented in user application.With the proposed API, user must first call
remote_wakeup(true)
and then must ensure to callremote_wakeup(false)
during 1-15 ms time window. This can be implemented with a simple counter e.g. like this:This PR also includes a fix of setting
LP_MODE
bit when suspending. I noticed that setting bothFSUSP
andLP_MODE
results in some weird behaviour where my application doesn't know that suspend happened. I am not sure what is causing this, but changingsuspend()
to first setFSUSP
and then in separate memory access setLP_MODE
fixes the issue. The reference manual describes the procedure:So another reason for not setting
LP_MODE
is that user application might want (and should) perform actions to reduce power consumption. For these reasons I added a separate methodsuspend_low_power_mode
which can be used by the application to perform any additional steps.Both methods make sure that we never set these bits when not in suspend state.