Hi Michael
I have realised that your test is in fact quite an interesting case so I set up something similar in a uTasker project configuration on the same board:
#define FRDM_K22F // build for freedom board
#define RUN_FROM_LIRC // clock directly from internal 4MHz RC clock
#define FLEX_CLOCK_DIVIDE 5 // 4/5 to give 800kHz
#define FLASH_CLOCK_DIVIDE 5 // 4/5 to give 800kHz
#define BUS_CLOCK_DIVIDE 5 // 4/5 to give 800kHz
#define SUPPORT_LPTMR // enable low power timer driver
#define TICK_USES_LPTMR // use low power timer for TICK so that it continues to operate in stop based low power modes (rather than Systick)
#define LPTMR_CLOCK_EXTERNAL_32kHz // clock the low power timer from external 32kHz reference
#define LPTMR_CLOCK_RTC_32kHz // use the RTC oscillator as ERCLK32k source
#define _TICK_RESOLUTION TICK_UNIT_US(500) // 500us tick interrupt
#define SUPPORT_LOW_POWER // a low power task supervises power reduction when possible
With this configuration I get more or less your case, whereby the details are automated.
In the code I add a couple of port outputs (similar to yours) for visibility and I set the low power state that should be automatically entered on no system activity:
fnSetLowPowerMode(VLPS_MODE);
I can also set LLS if I want since the LPTR will also wake from these (I set a LLWU event on it):
INTERRUPT_SETUP interrupt_setup; // interrupt configuration parameters
interrupt_setup.int_type = WAKEUP_INTERRUPT;
interrupt_setup.int_port = PORT_MODULE; // define a wakeup interrupt on a module
interrupt_setup.int_port_bits = (MODULE_LPTMR0); // wakeup on low power timer match
interrupt_setup.int_handler = 0; // no handler since it will be serviced by the tick interrupt
fnConfigureInterrupt((void *)&interrupt_setup); // configure interrupt
The first things to note are:
1. I set 800kHz flash clock since if you want to use VLPR and VLPW this is the maximum that it can have. You didn't state what Flash/Bus clock rate you have.
2. The second thing to consider is the basic interrupt latency involved. This is 12 cycles for the Cortex M4, but with FPU it increases to 29 (unless lazy stacking is used). I am assuming our K22 with FPU is taking 29 cycles (in fact it may be best to use a non-FPU in some cases!). 29 cycle at 4MHz are 7.25us. There are a few additional cycles needed to save registers in the interrupt handler and to read the interrupt vector and to set the outputs, so let's say 35 (8.75us). The interrupt vector may be taken from Flash and instructions are probably in flash and there may be some extra delay on actually loading these (800kHz) depending on cache state.
When I didn't use the VLPS (always run) I measure about 9.5us (+3us/0us jitter), which is fairly close to the expected value.
When I use VLPS mode between operations I measure 12.0us with about +/- 0.1us jitter.
What I see is that there is a delay of 1.7us between the LPTMR rising edge and the completion of the first instruction in code (I set an output for visibility).
Since my results don't show the >20us delays that you have I suggest that you need to revisit the tests to check the basics (maybe without low power switching to verify the interrupt basics).
The other questions that I would also ask is whether a KL series device may in fact be more suitable for your application? They are more streamlines for low power and if you use a slow clock there is not much point in the fast K22 (nor its FPU).
These are my analyser shot as comparison:
The top is of course the 32kHz clock.
The falling edge on the lower trace is the IRQ that the LPTMR triggers (and the delay from the clock's rising edge to it is 12us). This low pulse is the uTasker OS TICK handler, which will schedule a task (that runs at every tick).
The middle trace shows the instruction just after moving back from VLPS to RUN (immediate rising edge) - it then enables interrupts so that the interrupt that woke from the VLPS mode can actually fire (the VLPS state needs to be entered with disabled interrupts to avoid risk of system failure!!).
The middle trace toggles (low) again in the task that is scheduled.
It is interesting to note that the delay from the LPTMR wakeup and the task being scheduled is also very exact/consistent due to the fact that there is no randomness (the wake up always continues from the exact same code location after the IRQ). The OS will set the low power state after the task has run, it has verified that nothing else needs to be executed and it is safe to sleep again - the middle trace goes high again when the next VLPS state is commanded.
The reason why I set 500us period (and not 122us) is because the complete cycle is around 170us due to the OS operation and if I set it lower it will not be able to sleep since the next LPTMS Tick already arrives before it can. The ratio of VLPS and RUN is then also not of interest because it will be in RUN mode too much of the time (percentage).
This raises another interesting question which is also a frequent subject in low power designs. You have set a very slow processor clock and it is causes the OS operation (since it has too many timers, queues, tasks to be checked in my configuration) to take either too long or a high percentage of the cycle period. The result is a high percentage in RUN and only a small benefit from the VLPS (or other) mode. This can be quite inefficient.
The other strategy is to sleep deep for as long as possible, then run "as fast as possible" (to keep RUN time short) to get back to sleep as soon as possible. Then there is a high percentage of low power in the cycle - a high short current peak but an average consumption which is still very low.
Which ever chip you finally go for you may find it useful to consider which strategy is actually best based on the specific application and its cycle requirements. The advantage of the uTasker project is that I can run the exact same method on any Kinetsi (K, KL, etc.) without any changes (apart for the board define and clock speeds) so I can just chose the type that is finally used whenever it has been identified.
Probably in this design I would not have any tasks and do the IRQ handling directly in the interrupt.
Alternatively it is in fact not even necessary to have an interrupt (in the cycling case and single wake up source) since the handling code can immediately be executed after the sleep instruction, thus even saving interrupt latency!
Tell me how you get on and if you see anything else worth investigating further.
Regards
Mark
Thanks for helping out on this. Its really helpful. Disabling interrupts before vlps rings a bell, why is this? I've added it in, and added another gpio for the main loop 'WAKE' which goes high immediately after _WFI(), and low immediately before.
attached image - this time the led is showing yellow so i knew it was switching quickly between red and green. i can see that as you suggested things are taking too long.
the third 'IRQ pulse' comes early because it has not went back to sleep or disabled interupts yet. the LED shows that STOPA is set just before this.
I had set the Flash to 1MHz which i gues isnt helping if it needs to be <800KHz. maybe this is what is holding it up so much?
i will try to rework things to use the FLL at higher frequency. I'm aware of the low power schemes your suggesting and am planning on doing this.
Michael
As reference to what is achievable in VLPS and LLS when I move to low power cycle mode (that is I allow the low power loop to bypass the OS) I have the following recordings. I can switch between automatic mode and the OS bypassed mode as I want (eg. if I have a UART based command line exists I can run in the optimised loop to save most power but if I detect a UART interrupt pending I can temporarily switch to the full OS operation to handle the interaction with the user before returning to the optimised loop mode again.
In both cases I have the wake-up taking place on a LPTMR match, a virtual interrupt handler executing (I write "virtual" because the wake up was due to a pending interrupt and I never enable interrupt or have the interrupt latency involved).
Then it shows this cycle followed by a cycle which quits the loop to schedule tasks and such (which then needs to take the interrupt vector).
VLPS (close up)
1. LPTMR edge to processor executing instructions = 2us
2. Virtual interrupt handling taking place (bottom trace) 6us later
3. I have a short routine that just clears interrupts and does a counting function to set the mode back after a while takes 16us (shown further below)
4. VLPS mode entered again 3us after the handling is complete.
Therefore no interrupt latency and the RUN time is kept as short as possible
VLPS (low power cycle followed by 'normal' OS mode after the next wakeup)
The main observation is the interrupt latency and of course the OS overhead to schedule tasks and return back to the VLPS state (with its advantages at complete system level but as a trade off in that period). The recording in this section has been discussed in detail in previous posts.
LLS (closeup)
The wake-up time from LLS to RUN is much longer (25us as opposed to 2us) but the rest is the same as in the previous case since there is no interrupt latency issues (see next for comparison).
LLS(low power cycle followed by 'normal' OS mode after the next wakeup)
The delay between wakeup event and the start of handling it increases from 30us to 96us due to the interrupt latency (in second cycle).
This gives quite a good insight into the advantage of being able to control the RUN handling in such a cycle without needing to handle interrupts. It reduces the ratio of RUN to VLPS or LLS importantly and so can allow overall current to be reduced quite significantly (due to removal of interrupt latency overhead, especially after LLS wakeup!).
I can now control this in the uTasker project with the define
LOW_POWER_CYCLING_MODE
The call-back function that needs to be supplied is rather "low level" since it is up to the user to also ensure that wake up sources are cleared (this needs to be done also in the NVIC manually since the interrupt is not taken as normal). However this is all that is needed for a complete 'optimised' low power cycle based framework, also with the capability to switch between full scheduling or looping operation as one desires.
Once I have a video showing a complete system operating using this technique I'll give a link - where I will also show a little more details concerning the overall operation.
extern int fnVirtualWakeupInterruptHandler(int iDeepSleep)
{
if (iLowPowerLoopMode == 0) { // if not in low power loop mode ignore
return 0;
}
if (iDeepSleep == 0) { // loop only in deep sleep modes (not wait based)
return 0;
}
TOGGLE_TEST_OUTPUT(); // toggle output for measurement
LPTMR0_CSR = LPTMR0_CSR; // clear pending interrupt at LPTMR (wakeup source)
fnClearPending(irq_LPT_ID);
*(volatile unsigned char *)(LLWU_FLAG_ADDRESS + 2) = MODULE_LPTMR0;
// reset the wakeup flag (write '1' to clear) needed only from LLS
fnClearPending(irq_LL_wakeup_ID);
// Insert application specific code here....
//
iLowPowerLoopMode--; // go back to scheduler control after a number of cycles
TOGGLE_TEST_OUTPUT(); // toggle output for measurement
return 1; // stay in loop
}
Regards
Mark
Michael
If flash is secured it can be unlocked with KDS (it will tell you that it is secured and ask where you want it to un-secure it).
I have a couple of boards that stopped communicating (always the OpenSDA - as if it were dead).
In one case, while doing low power tests I found that I always corrupt the OpenSDA loader if I leave the current measurement jumper unconnected and connect to a Win 10 PC. This can be explained by the fact that (at least on that board) not having the target processor powered causes the OpenSDA chip (K20) to start in its own bootloader mode, which is not compatible with Win 10. Win 10 tries to write hidden files to its USB-MSD device and corrupts the loader. I can recover from this be reloading the OpenSDA loader on a Win 7 PC - I am very careful to not let this happen when doing current measurements but sometimes it still does....
To the issues:
- Basically if the system (however performed and whether in interrupts, main loop, tasks or in the "virtual Interrupt Handler") need 249us of every 250us cycle to do its work the maximum saving is 1/250% in terms of power reduction, even if there were zero overhead. The hard limit at the end of the day is therefore what the handler is doing - any additional overhead to control the handler (wake-up/sleep times, interrupt latency, task switching, other code in the system) is on top of this and so is best kept to a minimum.
- If I use the "LOW_POWER_CYCLING_ENABLED" state I have absolute maximum performance since there is neither interrupt latency, nor scheduling overhead. If I don't need or want the system to be responsive to other events I don't need to ever leave this state and so I can stay therefore.
- However I have the advantage that I can power up the system with the full operation (eg. allowing a user to configure the system in a comfortable manner if that is what the product also requires to be able to do). At some point I can switch to the optimal cycling mode with close to zero overhead.
- The further advantage is that I can temporarily switch to the full-operation (eg. at a defined time).
- If I want, as in the reference, I can still allow events - such as the command line console - to briefly go back to the full operation (with its higher power consumption) to handle the input. Of course if I don't want this I simply don't allow it.
Therefore there is no compromise if I want "pure" low power cycle operation. But in many real world designs one will still like to have other capabilities, even if only used once during the very first setup; after that it still has zero effect on the final operation and its efficiency.
To the currents:
There are unfortunately still some surprises which I can't (yet) fully explain. In the reference case the only activity outside the low power cycle loop is a RTC interrupt every 1s (negligable) plus the command line handling. The command line handling "only" takes place when used so if I don't touch the terminal it adds no overhead - if I do touch it the system requires more power for maybe one or two cycles - depending on what it needs to do. It doesn't affect the cycle operations though since this is still taking place in an interrupt and so no cycles are lost - it is only the temporary power consumption that is affected.
Therefore uTasker itself is not involved during the tests; no further activity whatsoever.
These are some things that I have noted concerning actual current consumption:
1. If I turn on my board (in WAIT mode, which means that the processor is set to the WAIT state with no activity (i.e. the 50% or so with the 25us cycle)) I measure 2.5mA. The current slowly increases up to about 3.5mA - possibly as the chip heats up (?). I didn't notice this effect in such tests before....and I have been doing them regularly on many different Kinetis parts for some years, whereby my typical TICK is 50ms (and not 250us).
2. If I test with 250us cycle time I really don't see the linear saving. It is as though there is an invisible period where the processor still consumes power - it doesn't follow the rule that you and I both expect that if the duration in each cycle is halved the current should halve. In fact there is very little difference in the current consumption between 50% and 100% duty cycle. It improves only when the duty cycle gets below about 40% or so.
I was in two minds as to whether it would be best to show a 250us or 500us cycle period. The results are NOT the same - it is as if this invisible "dead-time" is much less of a factor and the relationship is closer to that expected when the cycle period is increased.
Here is a complete set of measurements using 500us and 250us cycle so that you can see (4MHz core and 800kHz Flash so that VLPR is possible). There is some limit that can't be explained by the pure relation between being in RUN and being in VLPS (or other) since the waveforms measured show that the processor is RUNning for the same time in each case.
500us cycle period
RUN 4.2mA
WAIT 3.5mA (lpc has no used)
STOP 2.2mA (with lpc = 1.1mA)
VLPR 2.45mA (lpc has no effect)
VLPW 1.47mA (lpc has no effect)
VLPS 2.2mA (with lpc = 0.9mA)
LLS2 2.7mA (with lpc = 0.8mA)
This all makes pretty good sense - note that the low power loop mode is even more effective in LLS2 because we know that it save much higher interrupt latency (for previous investigations) so the theory and practice are doing quite well...
250us cycle period
RUN 4.2mA
WAIT 3.8mA (lpc has no used)
STOP 3.8mA (with lpc = 1.8mA)
VLPR 2.45mA (lpc has no effect)
VLPW 2.3mA (lpc has no effect)
VLPS 3.75mA (with lpc = 1.6mA)
LLS2 3.9mA (with lpc = 1.7mA)
I monitor the waveform in each case and the waveforms are as expected but one can see that the current is not. There are three interesting cases:
1. STOP mode is not effective at saving current in the 250us case, although the STOP mode is really entered for 50% of the time...!
2. VLPS is the same (makes sense because both are based on the STOP mode)
3. LLS mode is only effective when using the "low power cycle" mode due to the fact that its wake-up time is rather long and it can't quite achieve the rate - effectively it results in it always being in RUN mode since it has to wake up as soon as it gets there....With the LPC optimisation it can benefit from some decent sleep time....
My first suspicion is that there is some "energy" requirement to move to and from the STOP based modes that causes a "knee" in the current measurements and so a limit. Current saving only becomes effective when the STOP/RUN ratio is lower than around 35%. If this is not achieved it is basically useless...(at least in this configuration)
The overall conclusion is that one needs to TEST, TEST and TEST - also in the REAL conditions that the final product will be required to run under.
But I went a little further and checked what would happen if we allow the processor to run faster when it is not in a sleep state - setting the 48MHz IRC as clock to give 48MHz core and 24MHz Flash.
250us cycle period
RUN 17.0mA
WAIT 15.3mA (lpc has no used)
STOP 2.22mA (with lpc = 1.2mA)
VLPR - not possible
VLPW - not possible
VLPS 1.95mA (with lpc = 0.86mA)
LLS2 2.44mA (with lpc = 0.77mA)
As I have noted on several occasions - sometime sit is better to RUN fast and Sleep deep for as long as possible. These results show that the practice again follow the theory - this suggests more strongly that switching in and out of STOP mode with a slow clock is energy intensive because now we are running at a good speed when active and still achieving less current overall.
Now I also have no problems running as your preferred 122us cycle since even occasional scheduling overhead is peanuts overall in terms of actual overhead.
122us cycle period
RUN 16.8mA
WAIT 16.1mA (lpc has no used)
STOP 2.92mA (with lpc = 1.81mA)
VLPR - not possible
VLPW - not possible
VLPS 3.70mA (with lpc = 1.58mA)
LLS2 4.66mA (with lpc = 1.54mA)
I would probable choose VLPS with lpc at this faster working rate because I would also allow use USB optionally. These are the recordings at 122us for VLPS (without lpc) and (with lpc)
RUN/SLEEP ratio 12.58us/122us
RUN/SLEEP ratio 3.42us/122us
LPT saving 9.16us per 122us period, which equates to (real) 57% saving in power consumption.
Don't forget that I still have a complete system (the serial command shell reacts identically and if I want to use USB for a short period where the current consumption doesn't have priority I can so with without any effort). Therefore there is no advantage (only disadvantages in fiddly development/tests and potentially much higher costs and maintenance later when features need to be added) of not using the scheduler.
Regards
Mark
P.S. Would you like me to post binaries for you to test and verify your HW? Unfortunately I had to stop the 32kHz clock output because it shared the UART Tx line, so I need to disable the serial interface if the clock reference needs to be measured. Since the clock/wake-up delays (at least at 4MHz) are known I decided to not use it any more and just rely on the SLEEP/RUN ratios because the command line is extremely useful for doing efficient tests.
Alternatively, the uTasker development (including all this on the development branch) is available as GIT and SVN repository for uTasker users. If you want a free commercial license to avoid needing to rely on the NXP code (which is not designed for dynamic use) just tell me. I still support free users here - especially ones who are obviously clued up since it helps drive the development (which is already leaps and bounds beyond the NXP packages, but gets more ahead each day ;-)
Michael
I have performed some tests in LLS3 and have some interesting findings.
There is now a delay similar to the one that you measured.
Also note that in VLPS mode there is no problem with the debugger - only in LLS is it no longer possible to work with it.
These make me believe that you are somehow confusing LLS with VLPS.
The LLS wake up is however not as expected! This is what it now looks like:
The first marker is the edge which I believe wakes the processor from LLS mode. Now it takes 25.2us for the first instruction to be executed after waking, which is a lot longer than the max. 6us quoted in the data sheet; although the value in the data sheet if for 80MHz which suggests that our 4MHz clock is slowing recovery!
The next very surprising fact is that the wake up interrupt that caused the LLS to RUN recovery has a latency of 56us!!!!!!. I proved that the processor is executing instructions at the normal speed before taking the interrupt but it is much slower than when an interrupt is (normally) taken (typically around 8us with FPU state saving).
The second trace going high signals that the wakeup interrupt (due to LPTMR wakeup module) has been reached. This calls the OS tick handler (since the LPTMR interrupt is also pending anyway) and clears the sources - the bottom trace shows the actual tick handler being called from the LLWU interrupt.
Although not as extreme as when the interrupt is taken, returning from the LLWU interrupt also takes about twice as long as normal. This makes me wonder whether this exception is special in some way and is having to save and recover more information that other interrupts (?). In any case it looks to be similar to the approx. 23us that you have been puzzling over. In fact from the rising edge of CLKOUT32k to the IRQ I get about 82us, which means that you may be measuring from the wrong edge - the trigger was in fact 2 clock cycles before the one that you start measuring from !
The second trace flips bits for a while (I used this to prove that the interrupt is taken immediately and any slowness is not due to the interrupt being delayed - the bit flipping speed is the expected instruction speed). The rest is then as before.
Therefore I can show the operations in and out of VLPS and LLS3 to be basically equivalent in terms of the behavior flow but LLS3 recovery is taking unexpectedly long!
In fact, the LLS3 saving of current (about factor 3 over VLPS) is deteriorated due to the longer time that it takes to do the work in this sort of environment (quickly repeated cycle where the percentage of time in RUN should be kept as low as possible).
My feeling is therefore that VLPS is the one to go with (when the % of the period is fairly high. I would also look at running as fast as possible when in RUN to keep the time short. This may also help LLS performance since the LLWU interrupt latency should also be much better (it is presently dead-time which is consuming RUN mode current but does very little useful work that is visible and of any importance to the application). Also I would seriously consider a part without FPU to keep latency as low as possible.
If you have only one interrupt that does the cyclic work no interrupt is needed (as explained in previous post) and thus interrupt latency can be removed altogether.
Regards
Mark
