TWR-KW24D512 Low Power Demo power consumption

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

TWR-KW24D512 Low Power Demo power consumption

Jump to solution
651 Views
calebrust
Contributor III

I can’t get the TWR-KW24D512 demo board below ~210uA of current, any ideas?

 

I’m using the Low Power Demo (part of KW2xD_SMAC), and selecting MCU VLLS2, and Radio Hibernate, but power usage is above what I’d expect.  The firmware app implements a simple USB to serial terminal program (115200 baud)

C:\Freescale\KW2xD_SMAC\app\ieee_802_15_4\Low_Power_Demo\twrkw24d512\Source\Low_Power_DemoApp.c

 

I’m measuring current through two precision 1Ohm resistors I installed at R6 and R8. 

 

(R6=1Ohm) VdropR6 = 0.000050V. So the MCU is consuming 50uA

(R8=1Ohm) VdropR8 = 0.000160V. So the radio is consuming 160uA

 

Total = 210uA, over 10x what I expect!

 

…For resistor locations, see the schematic in Fig 3-9 of the TWR-KW2x reference manual

http://ds.arm.com/media/resources/db/platform/freescale/twr_kw21d256/TWR-KW2XHWRM.pdf

 

According to the Low-Power App note AN4857, the Radio should only consume ~1uA when in hibernate mode, and V_MCU should be 16.6-17.3uA while the MCU is in VLLS2.  It seems that there is a bug in the code, or some other source of power consumption.

http://cache.nxp.com/files/rf_if/doc/app_note/AN4857.pdf?fpsp=1&WT_TYPE=Application%20Notes&WT_VENDO... (Table 1 and Table 5)

 

In an effort to rule out a hardware problem, I tweaked the Low Power Demo firmware, and loaded it on my own KW2x board.  I’m experiencing very similar power consumption(250uA) in hibernate and VLLS2.  I believe there is some issue in the Low Power Demo source code?  I've attached the .srec file for anyone who might want to try it out on their TWR-KW24D512 board.

Original Attachment has been moved to: Low_Power_Demo.srec.zip

0 Kudos
1 Solution
457 Views
calebrust
Contributor III

I figured it out.  There were 2 I/O that were consuming extra power due to bugs in the firmware:

  1. PORTC0, which is internally tied to the radio GPIO5 was consuming 140uA.  The issue is that the pin is configured as output-low during clock initialization in the BOARD_ExtClk_Setup_HookUp() function, and it's not configured back to high-z (or disabled) prior to sleep.  Adding PORT_HAL_SetMuxMode(PORTC,0u,kPortPinDisabled); after clock initialization corrected this issue.  The radio probably has a 22k pull-up internally, so it just sat there and drained power.
  2. PORTD4, which is a simple LED control pin.  The issue is that the LED_Operate() function does not toggle between output-low and high impedance.  Rather, it toggles between output high and output low.  To fix, simply edit the gLedOff_c: case within the LED_Operate() function.  Remove GPIO_DRV_SetPinOutput(kGpioLED1);, and replace it with PORT_HAL_SetMuxMode(PORTD,4u,kPortPinDisabled);

After these 2 changes, the power consumption drops to the ~15uA range, which agrees with documentation.

View solution in original post

0 Kudos
1 Reply
458 Views
calebrust
Contributor III

I figured it out.  There were 2 I/O that were consuming extra power due to bugs in the firmware:

  1. PORTC0, which is internally tied to the radio GPIO5 was consuming 140uA.  The issue is that the pin is configured as output-low during clock initialization in the BOARD_ExtClk_Setup_HookUp() function, and it's not configured back to high-z (or disabled) prior to sleep.  Adding PORT_HAL_SetMuxMode(PORTC,0u,kPortPinDisabled); after clock initialization corrected this issue.  The radio probably has a 22k pull-up internally, so it just sat there and drained power.
  2. PORTD4, which is a simple LED control pin.  The issue is that the LED_Operate() function does not toggle between output-low and high impedance.  Rather, it toggles between output high and output low.  To fix, simply edit the gLedOff_c: case within the LED_Operate() function.  Remove GPIO_DRV_SetPinOutput(kGpioLED1);, and replace it with PORT_HAL_SetMuxMode(PORTD,4u,kPortPinDisabled);

After these 2 changes, the power consumption drops to the ~15uA range, which agrees with documentation.

0 Kudos