One of the projects I’m working on I chose to use one of the new Freescale KL25 MCUs. They have an ARM Cortex-M0+ core and lots of peripherals to boot, including ones specifically designed for low power usage. Below are some of the reasons why I chose it, and what my experiences with it have been.
Why the KL25?
Initially when I chose the KL25 my criteria was an MCU with a few KB of RAM for text buffers and a timer/counter that can operate as a counter with almost everything else shut off on the chip. I can get quite a bit of RAM on the KL25 and its low power timer can operate in counter mode with almost everything else shut off on the chip. The other thing it has going for it is that it has an ARM Cortex core in it. A proprietary core is a drawback for me when ARM has the one
ring core to rule them all. I don’t have to learn a new interrupt controller every time or a new whatever. Don’t get me wrong, everyone has their own peripherals, but as far as the different Cortex cores go, it’s just remembering which instructions are in which core.
I picked up one of the FRDM-KL25 boards to give it a dry run. The IDE I used was the CodeWarrior 10.3 beta. First up, the Processor Expert tool was a life saver. The clocking on the KL25 is rather involved and it takes up to three different clock modes to get to your final mode. The complexity comes with the flexibility the processor provides. Processor Expert is great, even if all you do is cut the code out that it generates and paste it into your own application. Without it, I don’t know if i would have made it past setting up the clock. After that it was a matter of setting up the different peripherals and going. I didn’t use DMA or interrupts for my first trial, just polling.
Onto a Custom Board
After it working for our initial prototype, we did up a custom board with the KL25 on it. The only issue I had there was that my clocks wouldn’t start. It turns out that I fried the MCU the first time I powered it up. Four dead chips later I figured out that the example I was coping the RTC code from used a crystal, not an external clock chip. So, whenever I “enabled the oscillator,” the MCU and external clock were fighting who was driving the CLK_IN pin and it killed the clock. It turns out that step can be omitted when using an external clock.
I was a little surprised that only two of the five GPIO banks are capable of interrupts. I had expected all of them to. That just meant I had to be a little more careful with what i attached to which pin.
The KL25 has an up to 16-bit ADC. However, the internal voltage reference is only good to +/- 3%. That gives me six bits of accuracy for the voltage reference… which gives me six bits of absolute accuracy for a 16-bit measurement unless I attach an external voltage reference that is more precise. I will say that I am happy with the temperature I am getting out of the internal temperature diode. The first time I programmed it up I got within about 0.1 °C of what I expected. One thing I will nit-pick about the ADC documentation is the “alternate” voltage reference that can be set. I tried using it since I did not connect the external analog power pins initially. I was able to read the internal voltage reference and temperature diode just fine, but external readings were way off. After I connected the external analog voltage pins, VDDA & VSSA, the external readings were good. I like that the ADC will do reading averaging by itself without intervention from the core. I tell it to get me the reading from a channel and put the core into a wait state until the ADC tells me it’s done with its readings.
I like the KL25 and hope that it works out well in the long run. To finesse the lowest power out of it takes some doing and I figure my code base will undergo several revisions as I push to get the current draw down as low as it can go. A lot of that will be mastering the clocking of the chip and putting enough intelligence into the program so that it will change the peripheral clocking when the core is put into one of the low power modes.