Adapting tpm_simple_pwm.c to run in VLPR mode

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

Adapting tpm_simple_pwm.c to run in VLPR mode

Jump to solution
799 Views
robertpoor
Senior Contributor I

I'm trying to adapt the tpm_simple_pwm.c driver example for a FRDM-KL27Z board to run in VLPR mode:

file: SDK_2.1_FRDM-KL27Z/boards/frdmkl27z/driver_examples/tpm/simple_pwm/tpm_simple_pwm.c

In the original code, I observe the output PTB18 generating time-varying PWM signals as expected.  But after my changes to the code, PTB18 appears to be floating at ~2V and there's no PWM signal. 

In tpm_simple_pwm.c, I changed this:

/* Get source clock for TPM driver */

#define TPM_SOURCE_CLOCK CLOCK_GetFreq(kCLOCK_McgIrc48MClk)

...

/* Board pin, clock, debug console init */
BOARD_InitPins();
BOARD_BootClockRUN();
BOARD_InitDebugConsole();
/* Select the clock source for the TPM counter as MCGPLLCLK */
CLOCK_SetTpmClock(1U);

to this (changes in boldface):

/* Get source clock for TPM driver */

#define TPM_SOURCE_CLOCK CLOCK_GetFreq(kCLOCK_CoreSysClk)

...

/* Board pin, clock, debug console init */
BOARD_InitPins();
BOARD_BootClockVLPR();
APP_InitDebugConsole_InVLPR();
/* Select the clock source for the TPM counter as MCGPLLCLK */
CLOCK_SetTpmClock(1U);

Some points:

  • APP_InitDebugConsole_InVLPR() is a routine I've developed and tested elsewhere.  It appears to work just fine.
  • When running in normal mode (not VLPR), I can set TPM_SOURCE_CLOCK to be GetFreq(kCLOCK_CoreSysClk) and it works.
  • I don't expect to see the same PWM frequency in the modified code (because the clock is running at 2MHz rather than at 48MHz).
  • I've tried calling CLOCK_SetTpmClock(x) with values 1, 2 and 3.  No change.

Since I observe Port B18 floating at 2v rather than set to 0v or 3.3v, I am guessing that there may be some other register associated with Port B that must be enabled for low power mode.  But that's just a guess.

Any hints would be appreciated!

Labels (1)
Tags (4)
1 Solution
542 Views
mjbcswitzerland
Specialist V

Hi

I can't help with the examples that you are using but I have configured a project for the FRDM-KL27Z running at 4MHz system clock and 1MHz bus/Flash clock (the maximum allowed for VLPR), and generated a 1kHz PWM signal (20% high) on PTC3 (J2-15).


The binary can be check at:
http://www.utasker.com/kinetis/FRDM-KL27Z.html#VLPR

If you connect to the OpenSDA VCOM at 19'200 Baud you can enter the "administrator" menu where you can switch between low power modes (including VLPR and VLPW) in order to see the effect on the PWM output and the current consumption.


The default mode is WAIT mode, as shown, when the present low power mode is requested with the "show_lp" command:

#show_lp
0 = RUN
1 = WAIT [active]
2 = STOP
3 = VLPR
4 = VLPW
5 = VLPS
6 = LLS
7 = VLLS0
8 = VLLS1
9 = VLLS3

To set a different mode use (for example for VLPR)
#set_lp 3

which will subsequently show
#show_lp
0 = RUN
1 = WAIT
2 = STOP
3 = VLPR [active]
4 = VLPW
5 = VLPS
6 = LLS
7 = VLLS0
8 = VLLS1
9 = VLLS3

You will find that you can change back and forth between various modes but the very low power ones may lose PWM output (due to clocks stopping) and some can only recover from a reset.

I don't know what the restrictions are with the code that you base your tests on but the uTasker project configuration settings are listed at the link. The only thing that should really be needed is to ensure that the TPM is clocked from the MCGIRCLK.

Should you prefer a complete solution, including (approx.) real-time simulation to accelerate testing, debugging and general product development you can get it at the link too.

Here are typical current consumptions that I have measured:

RUN 1.3mA / WAIT 1.1mA / STOP 0.1mA / VLPR 1.2mA / VLPW 0.5mA / VLPS 3uA / LLS 27uA / VLLS0 27uA / VLLS1 27 uA / VLLS2 27uA / VLLS3 2uA

Regards

Mark

View solution in original post

4 Replies
542 Views
robertpoor
Senior Contributor I

Ah!  If your fast mode clock is 4MHz, then yes, that explains why RUN and VPLR modes are relatively close.

And thank you 2^n for the suggestion about J17 -- that will make it easy to measure power consumption.

Best!

0 Kudos
543 Views
mjbcswitzerland
Specialist V

Hi

I can't help with the examples that you are using but I have configured a project for the FRDM-KL27Z running at 4MHz system clock and 1MHz bus/Flash clock (the maximum allowed for VLPR), and generated a 1kHz PWM signal (20% high) on PTC3 (J2-15).


The binary can be check at:
http://www.utasker.com/kinetis/FRDM-KL27Z.html#VLPR

If you connect to the OpenSDA VCOM at 19'200 Baud you can enter the "administrator" menu where you can switch between low power modes (including VLPR and VLPW) in order to see the effect on the PWM output and the current consumption.


The default mode is WAIT mode, as shown, when the present low power mode is requested with the "show_lp" command:

#show_lp
0 = RUN
1 = WAIT [active]
2 = STOP
3 = VLPR
4 = VLPW
5 = VLPS
6 = LLS
7 = VLLS0
8 = VLLS1
9 = VLLS3

To set a different mode use (for example for VLPR)
#set_lp 3

which will subsequently show
#show_lp
0 = RUN
1 = WAIT
2 = STOP
3 = VLPR [active]
4 = VLPW
5 = VLPS
6 = LLS
7 = VLLS0
8 = VLLS1
9 = VLLS3

You will find that you can change back and forth between various modes but the very low power ones may lose PWM output (due to clocks stopping) and some can only recover from a reset.

I don't know what the restrictions are with the code that you base your tests on but the uTasker project configuration settings are listed at the link. The only thing that should really be needed is to ensure that the TPM is clocked from the MCGIRCLK.

Should you prefer a complete solution, including (approx.) real-time simulation to accelerate testing, debugging and general product development you can get it at the link too.

Here are typical current consumptions that I have measured:

RUN 1.3mA / WAIT 1.1mA / STOP 0.1mA / VLPR 1.2mA / VLPW 0.5mA / VLPS 3uA / LLS 27uA / VLLS0 27uA / VLLS1 27 uA / VLLS2 27uA / VLLS3 2uA

Regards

Mark

542 Views
robertpoor
Senior Contributor I

Your reply got me over the hump: I wasn't setting the TMR source to MCGIRCLK.  Where I previously had:

CLOCK_SetTpmClock(1U);

I needed to change it to:

CLOCK_SetTpmClock(3U);

But what surprised me in your answer was this bit: 

Here are typical current consumptions that I have measured:

RUN 1.3mA / WAIT 1.1mA / STOP 0.1mA / VLPR 1.2mA / VLPW 0.5mA / VLPS 3uA / LLS 27uA / VLLS0 27uA / VLLS1 27 uA / VLLS2 27uA / VLLS3 2uA

The difference in current consumption in your observed between RUN (1.3mA) and VLPR (1.2mA) is much smaller than I expected.  

Drawing upon sources such as http://www.nxp.com/assets/documents/data/en/application-notes/AN5088.pdf , I would expect the current draw for RUN mode to be higher ("expect typical IDDs from 4 to 6 mA") and for VPLR to be lower ("expect typical IDDs from 0.16 to 0.5 mA").  

I guess we'll have to bring out the microammeter once we get our breadboard up and programmed to find our own numbers.

0 Kudos
542 Views
mjbcswitzerland
Specialist V

Robert

The RUN mode in the reference is probably with a much faster clock. I tested with the system clock always at 4MHz, also in RUN mode and so the difference will be smaller than switching on the fly between high speed clock in RUN and low speed clock in VLPR (switching on the fly is also more complicated since it requires all peripheral clocks to be recalculated and the risk of peripheral glitching or inaccuracies). I also find the VLPR that I measured to be rather high but it also depends on which peripherals are in use and in every low power design each clock, each peripheral etc. must be considered carefully to get the best results that are allowed for the specific functional requirements.

For my tests I simply take the uTasker project, choose the board and processor, and set a few defines to allow the intended operation speeds, plus enable PWM to check that functionality (it being the main topic of your post). Then I enable its low power support in order to get a complete operation framework to do checking for your case and measure initial currents in all modes. This framework is suitable for all project developments but is still "general" - the next step would be to configure more accurately specific project details to optimise (involving defining which clocks still need to run or can be stopped in the mode that will be required).

Regards

Mark

P.S. Put a jumper on J17 on the FRDM-KL27Z board (and remove the shunt resistors) to allow accurate current consumption measurements. Verify the measurement regularly during development to avoid surprises and make sure that all unused pins are set as outputs or pulled up/down (including peripherals) to avoid unexpectedly currents due to floating lines.