There is a PCB track problem that makes MCU power tests impossible with the FRDM board.

However I have tested using a stand alone MCU and have obtained the following results by changing the Clock Set Up mode in the Mbed-SRC library file "system_MKL05Z4.c"

VDD = 3.3022v, Temp = 19'c

Clock Set Up 0 ... Wake 5.420mA, Sleep 3.573mA, Deep Sleep 2.6uA

Clock Set Up 1 ... Wake 5.995mA, Sleep 3.833mA, Deep Sleep 2.6uA (this is the default set up)

Clock Set Up 2 ... Wake 1.447mA, Sleep 1.270mA, Deep Sleep 2.6uA

Wake, Sleep and Deep Sleep timers remained accurate during power mode transitions.

Further checks on default clock set up 1 and the RTC is usable on this MCU. RTC Clock source is generated in the MCU and not from an external source whereas the FRDM-KL25Z RTC is clocked from the SWD interface MCU. This results in loss of RTC timing on reset along with the inconvenience of feeding an external RTC clock source on stand alone MCU configurations.

The external 32kHz crystal remains in operation during Sleep and Deep Sleep modes. RTC registers and timing continue on a hardware reset so time accuracy is not lost.

The only issue I have so far is the compiler appears not to be very well optimised, an identical program on the KL05Z used 23k compared with 16k on the LPC812 MCU.

Further tests and I have found the RTC to keep very good time, +3 seconds over 24 hours on my board where the crystal runs at 32.770kHz. This is much the same as the LPC1768 RTC module. Another observation and I find that the RTC registers doe not reset when SWD downloading, timing remains accurate only resetting when power is cycled.

The LPC800-MAX uses microlib while the FRDM-KL05Z uses the standard library.

Could this be employed for the KL05Z platform? or better still could Mbed incorporate an optimisation option in the future similar to Keil. This would be advantageous for small flash size MCU's.

I saw that myself yesterday, and mailed Martin if I could just set the online target to use uARM or if I then break stuff ;). I think it is a simple change, especially since uARM is in the supported list, but this is one I am not too familiar with. Maybe someone here from mbed knows?

Ideally it would optimize as much as possible for speed, as long as it fits in flash, but I don't think compilers are smart enough to do that. I don't know how much optimization settings change the binary size, but in the end maybe they should be set for space on the smallest targets. However that is another story, initially it should just use uARM for online compiling.

MicroLIB does work here, I exported my program to uVsion and made these changes to the startup.MKL05Z4.s file so it would compile using MicroLIB.

http://mbed.org/questions/2667/Mbed-export-for-uVision-microlib/

EDIT..

MicroLIB now operational, works no problems (at time of writing).

Low power DCF77 RTC clock example here:

http://mbed.org/users/star297/code/KL05Z_DCF77_RTC_Clock/

Are the three clock setup modes fully supported by the mbed API? That is, will changing clock setup break some other mbed function such as delay, tick, uart or i2c frequency? Is it possible to change the KL0Z wake clock to some intermediate speed (e.g. 12MHz) to reduce the wake current?

Thanks, Tom

This MCU works best with default 32KHz crystal set up. Using slower core speed did work as far as I can remember, however it proved more energy efficient to put the MCU into deepsleep where possible and wake at the higher speed when needed.

Erik's WakeUp library does work very well here:

https://developer.mbed.org/users/Sissors/code/WakeUp/

Sound good, thanks.

Which KL05Z pins can wake from deepsleep using InterruptIn class? Is it the pins marked as IRQ_ in the datasheet or the pins marked LLWU_ ?

Thanks, Tom

The KL05, and every other mbed target I am aware of except the LPC1114, can use every InterruptIn to wake from deepsleep. There is a lower power mode than deepsleep, which is not supported by mbed and a pain to use, which requires special pins.

Other speeds should work, however all prescalers and values are only set once: So it should work to for example run it at 12MHz, but if you first run it at 48MHz, and then switch to 12MHz, most things will run 4 times too slow (not everything since some again have different clock sources).

I agree with Paul: Easiest is to stick to one clock speed, preferably the default, but you can try others (you might lose some accuracy in baudrate, wait time, etc), and then use deepsleep for further power reduction. Going into deepsleep is by far the best method to reduce your power consumption.