More and more of my students are using Microsoft Windows 10 machines, and my computer has been upgraded to Windows 10 a couple of week ago too. From my work and experience, a new operating system causes always some challenges, and Windows 10 is no difference. And no, this is not about Microsoft vs. Apple vs. Linux, this post is about addressing a potential and painful problem which I have observed with Windows 10 machines, and to my understanding it could happen with any other operating system too. The problem is that somehow on several student machines the bootloader and OpenSDA application on their FRDM boards did not work any more.
Windows 10 and OpenSDA Bootloader
I’m not really clear what it is causing this, but the boards which did not work any more had somehow the OpenSDA V2.x bootloader affected:
- I happened 6 times during last semester.
- In all cases a Windows 10 machine was involved.
- It is not clear under which circumstances it happened, it seems to happen rather random, and if the board has been put into BOOTLOADER mode.
The OpenSDA application and bootloader enumerates as virtual MSD (Mass Storage Device) to the host. My speculation is that somehow the host machines read/writes to that device in a way to confuse the bootloader/application on the board. As a result it seems to me that this leads to some programming sequences which then invalidate and corrupt the bootloader and application on it.
Affected OpenSDA Firmware
Only OpenSDA V2.0 (NXP FRDM-K64F) and OpenSDA V2.1 (NXP FRDM-K22F) boards were affected: these board have an ‘unsecured’ (mbed) bootloader on it which can be overwritten as it is open. The OpenSDA V1.0 bootloader (produced by P&E) on the other side seems not to be affected as the bootloader firmware is secured and protected, so it cannot be erased. So the problem seems to be related to the OpenSDA V2.x bootloader.
To find out if your firmware could be affected:
- Go to http://www.nxp.com/opensda and select your board
- Check if your bootloader is a V2, V2.1 or V2.x. If yes, you are potentially affected
If your firmware might be affected, you can
- Do nothing. The problem seems to be rather rare from my experience
- Be prepared to reprogram it with the original firmware.
- There is a new beta OpenSDA V2.2 firmware (see this link) which seems to be able to deal with the issue.
Either way with option 2 or 3, you need an external SWD/JTAG debug device/probe to reprogram the firmware on the Kinetis K20 OpenSDA microcontroller:
To reprogram the OpenSDA K20, you need first the bootloader firmware file. You might consider cloning it from a working second board (see “Recovering the FRDM-K64F Bootloader, or: Cloning the Program of a Microcontroller“).
The other way is to find and download the firmware from http://www.nxp.com/opensda:
💡 Be careful to select the correct bootloader file. The FRDM-K64F V2.0 bootloader uses a different base address for the application than the V2.1 one.
You might give the V2.2 firmware on new OpenSDA v2.2 Bootloader binary for FRDM-K22F a try. If flashing this to the FRDM-K64F, then you need to load V2.1 debug applications to it!
In any case, you need a separate/external device to re-program the bootloader. The recommended solution is to use either a Segger J-Link or a P&E Multilink. Alternatively another FRDM board like the FRDM-K64F can be used.
The easiest and simplest way is to use either the P&E Multilink or Segger J-Link. Locate the K20 on the Tower/Freedom board. Usually it is close to the K20 device:
Otherwise the OpenSDA on a FRDM or Tower board can be used. For this you
Flashing the Bootloader
If you don’t want to use an IDE, you can use the Segger J-Link Commander which is part of the Segger J-Link software package. It is part of Kinetis Design Studio too. Otherwise it is available from here.
- Launch the commander (jlink executable)
- Set the device: device MK20DX128xxx5
- Connect to the target if not already connected: connect
(use SWD and 4000 kHz)
- Load the binary: loadbin k20dx128_bootloader_0x5000.bin, 0
- Reset the device: r
- Quit the commander: exit
I can program the bootloader from Eclipse (e.g. Kinetis Design Studio too). Simply create a dummy project for the MK20DX128xxx5 device. In the debugger launch configuration specify the binary I want to use:
Using FRDM Board to Program another board
It is possible to use another FRDM board to program another board. Depending on the board, a SWD header needs to be soldered on the board and jumpers set or traces cut. Below are a few articles outlining the various ways for different boards:
- FRDM-KL25Z: https://mcuoneclipse.com/2012/11/07/jtagswd-debugging-with-the-frdm-kl25z-board/
- FRDM-KL25Z: https://mcuoneclipse.com/2013/04/27/debug-external-processors-with-usbdm-and-freedom-board/
- FRDM-KL25Z: https://mcuoneclipse.com/2013/04/21/using-the-freedom-board-as-jtag-programmer/
- FRDM-KL43Z: https://mcuoneclipse.com/2015/08/19/using-the-freescale-freedom-frdm-kl43z-to-debug-other-boards/
- FRDM-K64F: https://mcuoneclipse.com/2015/09/08/using-frdm-k64f-board-to-debug-another-kinetis-board/
💡 Keep in mind that the Segger license agreement only allow to program an evaluation board (FRDM, TWR, etc), not a custom hardware. The P&E OpenSDA V1 debug firmware does *not* allow to program any off-board devices.
Windows 10 can corrupt an OpenSDA V2.x bootloader. To recover the bootloader I need a programming device and the firmware file, then I can restore the bootloader. While I could use another FRDM board to recover it, it is much easier using a P&E Multilink or a Segger J-Link. Anyway I think for serious development I don’t want to depend on the OpenSDA interface only: to have a ‘real’ debug probe like in this case can safe many hours of work.
Happy Recovering 🙂
- OpenSDA overview: https://mcuoneclipse.com/2012/09/20/opensda-on-the-freedom-kl25z-board/
- NXP OpenSDA: http://www.nxp.com/opensda
- P&E OpenSDA: http://www.pemicro.com/opensda/
- Seger OpenSDA: https://www.segger.com/opensda.html
- OpenSDA V2.2 beta firmware: https://developer.mbed.org/questions/68997/How-to-recover-FRDM-K22F/#answer10413
- Recovering FRDM-K64F Firmware: https://mcuoneclipse.com/2014/11/10/recovering-the-frdm-k64f-bootloader-or-cloning-the-program-of-a-microcontroller/
- Segger J-Link probes: https://www.segger.com/jlink-debug-probes.html
- P&E Multilink probes: http://www.pemicro.com/multilink/index.cfm