Getting KL25Z bootloader to work without Windows 7

The one thing I hate about the Freedom KL25Z boards is that they are shipped with a bootloader that doesn’t work.  More precisely, they are shipped with a bootloader that works only with Windows 7, not Mac OS X, not Linux, and not even Windows 8.  (Note: never get P&E Micro to do any software work for you—they are responsible for this crappy bootloader.)  There is a newer bootloader from P&E Micro, but you need a Windows 7 computer to download it, so that does no good at all (it’s worse than that: see below).

I bought a new KL25Z board recently, to replace one that my son borrowed for Futuristic Lights, and soldered up the headers today, and was ready to test it out. I was hoping that they were now using one of the newer P&E bootloaders, that supposedly works on Macs (I’ve never seen a P&E bootloader that works with Macs, but I was willing to believe that P&E got enough complaints that they eventually fixed their bugs). Unfortunately, what I got is

MicroBoot Kernel Version is: 1.05
Bootloader Version is: 1.09

but P&E Micro reports

Bootloader versions 1.10 and earlier are not allowing firmware update and MSD FLASH programming on my OpenSDA board, with the Linux, MacOS, or Windows 8/8.1 operating systems.

I understand that on some of their newer boards, Freescale is using the mbed.org bootloader, which is the one I want to install on my KL25Z board. My choices at this point seem to be:

• Take the 6.5-mile bicycle ride round-trip to campus to use an ancient Windows 7 machine from the circuits lab (this is what I’ve done in the past).
• Buy a Windows 7 laptop to use at home, for initializing KL25Z boards and for testing PteroDAQ multi-platform support.
• Look on the web for a workaround.
• Ask my son if he found a workaround for his Linux laptop.

I’m too lazy to bike to campus (I did that cycle ride 4 times in the last 6 days), and I can’t get a laptop delivered instantly (and it will take quite a bit to put aside my aversion to Windows enough to buy even an $85 used laptop with Windows). That leave the web search and asking my son.

I did find a workaround on the web for Windows 8 [https://community.freescale.com/message/440982#440982]:

Configure “Do not allow locations on removable drives to be added to libraries”  as discussed here: http://answers.microsoft.com/en-us/windows/forum/windows8_1-hardware/how-do-i-prevent-system-volume-information-files/815b0046-d631-4419-a43e-44083a3733f5 and you should be able to do updates from Windows 8.1.

I don’t know whether this workaround works, as I don’t have access to a Windows 8 machine to test it on.

My son pointed me to a workaround that has been posted for Linux systems [http://karibe.co.ke/2014/04/changing-the-firmware-on-freescale-freedom-boards-in-linux/], and that he has used successfully. I tried that on Mac OS X, but the utilities for manipulating mounting of disks is different—you need to use ‘diskutil unmount’ and there is no “modprobe”.

I tried doing the closest corresponding actions on Mac OS X, but they did not work.  I could unmount and mount the disk easily enough (it showed up as /dev/disk1, which can be most easily discovered with ‘diskutil list’), but copying the mbed sda file to the disk still had no effect.

We tried the original script from karibe.co.ke on my son’s Linux laptop, and it worked ok.  We could install the mbed.org firmware (from https://developer.mbed.org/handbook/Firmware-FRDM-KL25Z) using the Linux script with the unmount/mount trick. The mbed software worked as usual to download PteroDAQ to the board.

I think tried some more experimenting. We updated the Bootloader to v1.11, using the latest download from P&E Micro, as pointed to by their OpenSDA page. The update worked, to the extent that the Bootloader reported being v1.11, instead of 1.09, but despite P&E’s claims, it still did not work with Mac OS X. I could not download P&E micro .SDA files nor  the 20140530_k20dx128_kl25z_if_opensda.s19 file from mbed.org.

So we used my son’s Linux laptop again to put the mbed software on the KL25Z board, and I’ll have to be carefully not to get into Bootloader mode unless either he’s around with his laptop or I’m willing to cycle to campus.  (Or I break down and get a junky Windows laptop just for rebooting KL25Z boards.)

My son has been suggesting that we get a junky Windows box, so that he can test out the multi-platform features of PteroDAQ without having to cycle to campus with me.  I might do that while he is away at Ashland next week, if I can find a cheap enough laptop that I believe will actually function.

Hysteresis lab on KL25Z

Relaxation oscillator used in the hysteresis lab. The “variable capacitor” in this schematic is a person’s finger and a touch plate made from aluminum foil and packing tape.

I spent today writing code for the KL25Z board to act as a period or frequency detector for the hysteresis lab, where they build a relaxation oscillator using a 74HC14N Schmitt trigger inverter and use it to make a capacitance touch sensor (pictures of last year’s setup in Weekend work). I had written code for the Arduino boards last year, and I started by trying to do the same thing on the KL25Z, using the MBED online development system.  The Arduino code used “PulseIn()” to measure pulse duration, and the MBED system does not have an equivalent function.  I could have implemented PulseIn() with a couple of busy waits and a microsecond-resolution timer, but I decided to try using “InterruptIn” to get interrupts on each rising edge instead.

The basic idea of last year’s code (and the first couple versions I wrote today) was to determine the pulse duration or period when the board is reset, finding the maximum over a few hundred cycles, and using that as a set point to create two thresholds for switching an LED on or off. I got the code working, but I was not happy with it as a tool for the students to use.

The biggest problem is that the touch plate couples in 60Hz noise from the user’s finger, so the oscillator output signal is frequency modulated.  This frequency modulation can be large compared with the change in frequency from touching or not touching the plate (depending on how big C1 is), so setting the resistor and capacitor values for the oscillator got rather tricky, and the results were unreliable.

I then changed from reading instantaneous period to measuring frequency by counting edges in a 1/60th-second window.  That way the 60Hz frequency modulation of the oscillator gets averaged out, and we can get a fairly stable frequency reading.  The elimination of the 60Hz noise allows me to use less hysteresis in the on/off decision for the LED, making the touch sensor more sensitive without getting flicker on transitions. The code worked fairly well, but I was not happy with the maximum frequency that it could handle—the touch sensor gets more sensitive if C1 is small, which tends to result in high frequency oscillations. The problem with the code was that MBED’s InterruptIn implementation seems to have a lot of overhead, and the code missed the edge interrupts if they came more often than about every 12µsec.  Because I was interrupting on both rising and falling edges, the effective maximum frequency was about 40kHz, which was much lower than I wanted.

To fix the frequency limitation, I replaced MBED’s InterruptIn with my own interrupt service routine for PortD (I was using pin PTD4 as the interrupt input). With this change, I could go to about 800kHz (1.6e6 interrupts per second), which is plenty for this lab.  If I wanted to go to higher frequencies, I’d look at only rising edges, rather than rising+falling edges, to get another factor of two at the high end.  I didn’t make that change, because doing so would reduce the resolution of the frequency measurement at the low end, and I didn’t think that the tradeoff was worth it here.

The code is now robust to fairly large variations in the oscillator design.  It needs a 20% drop in frequency to turn on the green LED, but the initial frequency can be anywhere in the range 400Hz–800kHz.

To make it easier for students to debug their circuits, I took advantage of having an RGB LED on the board to indicate the state of the program: on reset, the LED is yellow, turning blue once a proper oscillator input has been detected, or red if the oscillator frequency is not in range. When the frequency drops sufficiently, the LED turns from blue to green, turning back to blue when the frequency goes up again.

For even more debugging help, I output the frequency that the board sees through the USB serial connection every 1/60th second, so that a program like the Arduino serial monitor can be used to see how much the frequency is changing.  I took advantage of that feature to make a plot of the frequency as the touch sensor was touched.

Plot of frequency of hysteresis oscillator, as the touch pad is touched three times. Note that the thresholds are very conservatively set relative to the noise, but that the sensitivity is still much higher than needed to detect the finger touches.

Overall, I think that the code for the KL25Z is better than what I wrote last year for the Arduino—now I have to rewrite the lab handout to match! I actually need to update two lab handouts this weekend, since week 3 will have both the hysteresis lab and the sampling and aliasing lab. Unfortunately, the features needed for those labs (trigger on rising and falling edges and downsampling) are not working in PteroDAQ yet.

Here is the code that I wrote for the frequency detector:

// freq_detector_own_isr
// Kevin Karplus 
// 2014 Apr 5

// This program is intended to be used as a "capacitive touch sensor" 
// with an external relaxation oscillator whose frequency
// varies with the capacitance of a touch.

// The program expects a periodic square wave on pin PTD4 with a frequency between 
// about 400Hz and 800kHz. (LOW_FREQ_LIMIT and HIGH_FREQ_LIMIT).
// On reset, it displays a yellow light, then measures the frequency to store as the "off" frequency.
//
// If the frequency is out of range (say for a disconnected input), then the light is set to red, 
//     and the off frequency checked again.
// Otherwise the LED is turned blue.
// 
// After initialization, if the program detects a frequency 20% less than the initial freq, 
// it turns the light green, 
// turning it blue again when the the frequency increases to 90% of the original frequency.
//
// No floating-point is used, just integer arithmetic.
//
// Frequency measurements are made by counting the number of rising and falling edges
// in one cycle of the mains frequency (1/60 sec), giving somewhat poor resolution at lower 
// frequencies.  
// The counting time is chosen to that frequency modulation by the mains voltages is averaged out.
//
// This version of the code uses my own setup for the interrupt service routine, because InterruptIn has
// too much overhead.  I can go to over 800kHz (1.6e6 interrupts/second) with this setup, 
// but only about 40kHz (80e3) interrupts/sec with mbed's InterruptIn.

#include "mbed.h"

#define PCR_PORT_TO_USE (PORTD->PCR[4])   // pin PTD3 is the pin to use

#define MAINS_FREQ (60)     // frequency of electrical mains in Hz
#define COUNTING_TIME (1000000/MAINS_FREQ)   // duration in usec of one period of electrical mains

// off_frequency must be between LOW_FREQ_LIMIT and HIGH_FREQ_LIMIT for program to accept it
#define LOW_FREQ_LIMIT (400)
#define HIGH_FREQ_LIMIT (800000)

// on-board RGB LED
PwmOut rled(LED_RED);
PwmOut gled(LED_GREEN);
PwmOut bled(LED_BLUE);
#define PWM_PERIOD (255)  // for the on-board LEDs in microseconds

// Set the RGB led color to R,G,B  with 0 being off and PWM_PERIOD being full-on
void set_RGB_color(uint8_t R, uint8_t G, uint8_t B)
{
    rled.pulsewidth_us(PWM_PERIOD-R);
    gled.pulsewidth_us(PWM_PERIOD-G);
    bled.pulsewidth_us(PWM_PERIOD-B);
}


// InterruptIn square_in(PTD4);
volatile uint32_t edges_counted;

uint32_t low_freq_threshold, high_freq_threshold;  // thresholds for detecting frequency changes


extern "C"{
// interrupt routine that counts edges into edges_counted
    void PORTD_IRQHandler(void) 
    {
       edges_counted++;
       PCR_PORT_TO_USE |= PORT_PCR_ISF_MASK;
    }
}

// return the frequency for the square_in input in Hz
uint32_t frequency(void)
{    
    PCR_PORT_TO_USE &= ~PORT_PCR_IRQC_MASK;  // disable interrupts on pin PTD3
    edges_counted=0;
    PCR_PORT_TO_USE |= PORT_PCR_ISF_MASK | PORT_PCR_IRQC(11);  // clear interrupt for PTD3, and enable interrupt on either edge
    wait_us(COUNTING_TIME);
    PCR_PORT_TO_USE &= ~PORT_PCR_IRQC_MASK;  // disable interrupts on pin PTD3
    uint32_t freq=edges_counted*MAINS_FREQ/2; 
    return freq; 
}



int main() 
{   
    rled.period_us(PWM_PERIOD);
    gled.period_us(PWM_PERIOD);
    bled.period_us(PWM_PERIOD);
    set_RGB_color(255,255,0);   // set light to yellow
    
    SIM->SCGC5 |= SIM_SCGC5_PORTD_MASK; // make sure port D has clocks on
    PCR_PORT_TO_USE &= ~PORT_PCR_MUX_MASK;  // clearing the MUX field
    PCR_PORT_TO_USE |= PORT_PCR_MUX(1);     // Setting pin as GPIO
    FPTD->PDDR &= ~ (1<<4);  // make sure pin is input pin
    NVIC_EnableIRQ(PORTD_IRQn);            // enable interrupts for port D
    
    __enable_irq();

    uint32_t off_frequency= frequency();
    while ( off_frequency<low_freq_limit ||="" off_frequency="">HIGH_FREQ_LIMIT)
    {   // timed out.  set color to red and keep trying
        set_RGB_color(255,0,0);
        printf("FREQ out of range: %luHz\n", off_frequency);
        off_frequency= frequency();
    }
    
    uint32_t low_freq= 8*off_frequency/10;  // 80% of off_frequency
    uint32_t high_freq= 9*off_frequency/10;  // 90% of off_frequency
    
    printf("off= %luHz lo_thresh=%luHz hi_thresh=%luHz\n",off_frequency, low_freq, high_freq);
    while(1) 
    {   uint32_t freq=frequency();
        printf("%lu Hz\n",freq);  
        if (freq < low_freq)
        {   // low_fequency found, turn LED green
            set_RGB_color(0,255,0);
        }
        else if (freq >= high_freq)
        {   // high frequency found, turn LED blue again
            set_RGB_color(0,0,255);
        }    
    }
}

Updates on some earlier lessons

In Still better I-V plot for Schottky diodes, I had some lessons learned at the end of the post:

1. Higher-resolution ADCs do give smoother curves, with less digitization noise, but they aren’t a panacea for measurement problems. To get most of the resolution, I had to set the ADC to use long sample times and do a lot of averaging. I understand that Freescale Kinetis M series include 24-bit sigma-delta converters for higher precision at much lower speed (24 bits is 7 decimal digits), as well as the high-speed 16-bit successive-approximation converters. Unfortunately, they don’t have a low-cost development board for this series.
2. Stay away from the bottom end of the ADC range on the KL25Z.  Scale single-ended inputs to have values at least 50, and differential inputs to have values at least 20.  There may be similar problems at the top end of the range, but I did not test for them.
   I wondered if the problem may be switching from the large value for the voltage across the diode to the small voltage across the shunt resistor that was the problem. I tried putting in a dummy read between the voltage and the current reads, but that didn’t help at all. At first I thought that the low-count readings were good with the large shunt resistors, but this is probably an illusion: errors in the current measurement for small currents aren’t visible on the plot, because the voltage across the diode is not changing, and so large horizontal errors in the plot are not visible there.
3. Watch out for AC noise when trying to measure DC parameters.  If there are semiconductor junctions around, the noise may be rectified to produce an unwanted DC signal.
4. The differential ADC settings have a range of ±VDDA, not ±VDDA/2. This means that the least-significant bit step size is twice as big for differential inputs as for single-ended inputs. For some reason the Freescale documentation never bothers to express what the differential range is.
5. Serial USB connections are a bit flakey—the Arduino serial monitor missed a byte about every 200–300 lines.  I looked for anomalous points on the plot, then commented out the lines that produced them—they were almost all explainable by one character having been missed by the serial monitor; e.g., I commented out “662401069     86      19″ right after “660001069       865     17″,  because the last digit of the voltage (the second field) was missing.  The fields were a timestamp (in 24MHz ticks), voltage across the diode (in ADC units), and voltage across the shunt resistance (in ADC units).  [Actually, this was not a new lesson for me—I’ve had to do the same on almost all files collected from the Arduino serial monitor.  My son’s data logger code is better at not losing data, but it is still worthwhile to check for anomalies.]
6. The 3.3v supply from the Freedom board is much cleaner than the 5v USB supply that I get from the Arduino (unless I use an external power supply with the Arduino), but I can only take about 10mA from the 3.3v supply before it begins to droop.  If I want  more than that, I’d better provide my own power supply (or at least my own LDO regulator from the USB 5v supply).

I’d like to correct a few of those lessons in this post.

1. A 24-bit sigma-delta converter is really only about 7 bits of accuracy—you are relying on oversampling with a single-bit comparator, then low-pass filtering.  Your resolution is a function of frequency, but the “24-bit” number is misleading—that’s how much precision they carry in the low-pass filter computations, and has little to do with the amount of information you can actually extract from the ADC. I think I was confusing sigma-delta converters (which are fast, cheap, and not very accurate) with dual-slope converters (which are slow and more accurate).
2. no update.
3. no update.
4. no update.
5. The UART communication from the Freescale KL25Z boards, using MBED’s code on OpenSDA chip to do the UART to USB conversion is much less reliable than the Arduino serial connections.  My son has been doing testing and has found that he can run the Arduino boards up to about 500k baud without losing characters (aside from a small number right after a reset), but the MBED-implemented UART communication on the KL25Z lost tens of character per second even at fairly low speeds (tested own to 62.5kbaud). We suspect a bug in their code in which they ignore the UART port for too long while dealing with the USB side.  (He’s not the first to notice that the MBED serial communication is broken on the KL25Z boards.) Using the MBED USB stack natively on the KL25 chip (not the SDA port), he had no noticeable character losses, so the problem is not on the host computer or the software he was testing with, but on the MBED implementation of the USB serial connection on the OpenSDA chip.
   This bug in MBED’s serial implementation has raised the complexity of the port of the data acquisition system to the KL25Z enormously, as he’ll have to implement a USB stack (or enough of one to do USB serial) on the KL25, rather than using the buggy one on the OpenSDA chip.  The MBED USB stack (written in C++) is not compatible with the bare metal ARM platform he’s been using for the port (which only seems to support C).  He’s gotten the USB code to compile and link, but is having trouble getting it to run—we suspect that some part of the C++ memory management has not been initialized properly.
   We have not checked whether the PEMicro OpenSDA software works for serial communication—since it doesn’t work for downloading software from the Mac, we can’t use it anyway.
6. As I reported in Diode-connected nFET characterisitics, the 3.3V LDO on the KL25Z boards is actually pretty good: it can be modeled as 3.32V source with a 55mΩ series resistor. I got a steeper voltage drop above 500mA, but that was from overloading the USB 5v supply that was powering the board, not from problems with the LDO.
   I’ve not yet tried powering the board with a beefier power supply on the P5-9V_VIN pin. I suspect that it will be able to handle up to 1.5A without problems (maintaining the 55mΩ impedance).