Programming the MKE02Z64 Cortex-M0+

Although made by NXP the Cortex-M0+ chip used is one NXP inherited when they took over Freescale semiconductors in 2015, so the chip does not follow the usual NXP conventions. The chip is part of the Kinetis E family of ARM Cortex-M0+ based microcontrollers, and within this family it is within the KE02 sub-family. I am unsure of the level of compatibility with the KE04 sub-family but at a glance the only difference seems to be the number of pins. From the data-sheet the part number splits up as follows:-

Some of the parameters such as qualification are clearly superfluous, since the publicly available parts only have one available value. The documentation uses KE02Z as the family code, although I think it is more correct to use MKE02Z64 when referring to the chip in a package-independent way.

Using the microcontroller chip

Using general-purpose I/O

REG(0xf8000014) = 0x030fff00; // Port mask REG(0xf8000008) = 0x030fff00; // Clear bits REG(0xf8000004) = LCD_CS2 | LCD_RESET; // Set bits REG(0xf8000004) = 0x3f << 8; // Set bits /* delay omitted */ REG(0xf8000008) = LCD_CS2; // Clear bit REG(0xf8000004) = LCD_CS1; // Set bit /* delay ommited */

All but four of the GPIO-capable pins default to GPIO and of the four that don't three of them are used for programming/debugging functionality. All the essential information for FGPIO within the reference manual is contained within four pages (581–584), so there is not really that much to know in order to get up-and-running. This makes a nice change from PIC chips that tend to have analog functionality as reset defaults. However pin functionality is selected by whether various sub-systems are active or not, and they are subject to a priority ranking, rather than each pin having dedicated mode bits within a register.

Configuring internal chip clocking

Using a multi-meter to measure the actual frequency of a simple timing firmware toggling a GPIO pin at a 50% duty cycle with a period of 16,000 tics showed a reading of 994.6Hz, indicating an actual bus frequency of 15.91MHz. Checking the BDIV and BUSDIV registers using a debugger showed them to be the default values stated in the documentation, and changing BDIV resulted in the expected relative change in toggling frequency based on stated frequency divisions. From all of this the simplest conclusion is that the nominal output of the FLL is actually 32MHz. Having to figure this out experimentally leaves me unimpressed, and for tasks that need a known & accurate clock frequency I would recommend use of an external reference.

Using the Periodic Interrupt Timer

REG(0x4004800c) |= 0x02; // Activate timer clocking REG_PIT_MCR = 0; while(1) { REG_PIT_LDVAL0 = 16000000lu; REG_PIT_TFLG0 = 1; REG_PIT_TCTRL0 = 0x01; while(REG_PIT_TFLG0 == 0) { } REG_PIT_TCTRL0 = 0; /* ... */ }

In practice the timer would be either be polled in a much larger event loop, or interrupts would be used instead of polling. For most of the microcontroller firmwares I have written so far I have tended to avoid interrupts as they needlessly complicate program flow.

Using the Real-Time Clock

Using the RS232 UART

REG(0x4004800c) |= 1 << 21; // Enable UART1 clock REG8(0x4006b000) = 0; REG8(0x4006b001) = 104; // 9600 BAUD REG8(0x4006b002) = 0; // 1 stop bit; no parity REG8(0x4006b003) = 0x0c; // Enable both Tx and Rx while(1) { while( (REG8(0x4006b004) & 0x20) == 0 ) { // Wait for Rx to have data } data = REG8(0x4006b007); while( (REG8(0x4006b004) & 0x80) == 0 ) { // Wait for Tx to become idle } REG8(0x4006b007) = data; }

The UART has a sampling rate that is 16 times the target BAUD rate, and the reference manual presents some calculations for what difference in BAUD can be tolerated before errors get flagged up — for the typical eight data bits, parity, and one stop bit this is 3-4%. I wrote a Python script that works out the best parameters for a target BAUD given a main clock frequency and BDIV divisor. If a BAUD higher than 9,600 is required I would recommend using an external clock source, as I have read hints that the accuracy of the internal nominal-32kHz oscillator is not really up to the task, and I suspect that the use of a frequency-locked loop rather than a higher-frequency reference is particularly vulnerable to glitches.

Compared to the LPC11(U)xx where RS232 BAUD is specified as a fraction using multiple registers, setting the rate on the MKE02Z64 is rather primitive in that it is purely integer sub-division of the main clock. To make matters worse the granularity of the divisor is limited to multiples of 16, so some values cannot be obtained without either adjusting upstream clock prescalers that also affect other parts of the chip, or changing the trim of the main reference oscillator. On the plus side an interesting feature I saw in passing was the ability to chain together the UART and the FTM (FlexTimer Module), which is intended for RS232 over infra-red links, but for the time being I have no plans to try this feature out.

Using I²C functionality

Most of the actual trouble I had getting slave mode working was down to incorrect use of the Robot Electronics I²C-USB device rather than problems with my firmware, although a minor gotcha is that registers are cleared by writing a 1 rather than masking out the relevant bits using an AND operation. How to use I²C slave mode is shown in a serial demo firmware where I²C status is written to the RS232 connection and I²C reads use incrementing byte values.

Review

Clock accuracy

Quality of the documentation

Compared to the documentation of other NXP components I have used in the past, the Kinetis documentation is disappointing. It does have some very good sections that are down to the point, but large parts of the documentation feel like they were originally written to be stand-alone, as if they were mini-datasheets for sub-systems that were simply cut'n'pasted into the manual for the chips that use them. At quite an early stage I concluded that, due to what the documentation omitted — even though I figured out it was typically general ARM stuff rather than chip-specific — I simply cannot recommend this chip to anyone who has not had previous ARM experience with another product.

Comparison to Microchip PIC programming

While a part of me does miss PIC assembly there are relatively few projects I actually used it for the firmware in preference to C and in most cases I would be better off using ARM — C is the level of abstraction I normally think at, most of the time I just want to get the firmware done, and for C the development eco-system is simply a lot better. In practice PIC's notional advantages don't translate into lower costs. In addition, whereas I think it is very unlikely that I would ever use PIC microcontrollers professionally, having to do this type of bare-metal programming of ARM chips is within the bounds of realistic probability — at time of writing my professional work involves getting my fingers dirty with UBoot on an ARM-based Linux platform, and a professional future with ARM is why I started looking at Cortex-M chips in the first place.