Entering VLLS0 mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Entering VLLS0 mode

Jump to solution
612 Views
chipweller
Contributor II

We have a device which is using VLLS0 mode for sleeping. One of three GPIO / LLWU pins can wake the device, either on a single edge or on both depending on the pin. Both the sleep and wake operations work fine. There is a possible race condition when putting the device to sleep, where an external user action causes a pin to transition just before the WFI instruction. I am not sure how to handle this.

The processor is the MKL16Z256V. I have read AN4503 section 14.1.2 but that does not address all my concerns.

If I capture the transition on an edge, I still have to avoid executing the WFI instructions to have the system successfully respond to the user. My reading of section 14.1.2 suggests that the WFI instruction will be aborted if the interrupt occurs "just" before the instruction.

Q1: Does this cause the WFI instruction to reset the processor (the normal way out of VLLS0) or does it simply start executing the instruction following the WFI?

My current thought is when preparing to sleep:

  1. Set a flag.
  2. Check if no work required (which may have been queued before the flag was set). If work required, abort the enter VLLS0 operation and continue normal operation.
  3. In the ISRs if the flag is set when the edge occurs, force a reset.
  4. Enter the VLLS0 mode using WFI.
  5. [If execution continues past the WFI then force a reset.]

I have a way to address passing the edge information back to the main line after the reset, allowing for processing after the reset.

Q2: Is there anything missing from this approach?

Q3: Does anyone have a better approach?

Thanks in advance,

Chip

Tags (3)
1 Solution
472 Views
mjbcswitzerland
Specialist V

Chip

The AN is explaining how to work around this window because the low power mode is 'not' entered if there is a 'masked' interrupt when executed. This means that if you execute the sleep instruction expecting the VLLSx mode to be entered 'but' the instruction following the sleep is nevertheless reached it means that is was aborted due to a masked interrupt occuring during (or before) the window. The port interrupt will not be executed because the global interrupts will still be masked.

Since you expect VLLSx to be exited via a reset you can also command a reset immediately after the sleep instruction so that the result is equivalent.

This is the pseudo-code that I would use:

Enable LLWU input (any time before)

Prepare VLLSx low power mode (any time before)

...

// We want to go to VLSSx and reset on an edge on an input

disable interrupts

enable port interrupt

if GPIO is already in the triggered state RESET (in case edge was missed while enabling port interrupt)

sleep() - go to VLLSx

RESET - reset because the VLLSx mode was not entered (must have been due to a masked port interrupt aborting it)

Regards

Mark

View solution in original post

1 Reply
473 Views
mjbcswitzerland
Specialist V

Chip

The AN is explaining how to work around this window because the low power mode is 'not' entered if there is a 'masked' interrupt when executed. This means that if you execute the sleep instruction expecting the VLLSx mode to be entered 'but' the instruction following the sleep is nevertheless reached it means that is was aborted due to a masked interrupt occuring during (or before) the window. The port interrupt will not be executed because the global interrupts will still be masked.

Since you expect VLLSx to be exited via a reset you can also command a reset immediately after the sleep instruction so that the result is equivalent.

This is the pseudo-code that I would use:

Enable LLWU input (any time before)

Prepare VLLSx low power mode (any time before)

...

// We want to go to VLSSx and reset on an edge on an input

disable interrupts

enable port interrupt

if GPIO is already in the triggered state RESET (in case edge was missed while enabling port interrupt)

sleep() - go to VLLSx

RESET - reset because the VLLSx mode was not entered (must have been due to a masked port interrupt aborting it)

Regards

Mark