Bricking and Recovering OpenSDA Boards in Windows 8 and 10

Getting a board from a distributor like Farnell/Element14/Mouser (add your own distributor) means that chances are high that the default firmware on it was written years ago because the inventory was never updated or because boards are still produced with that original firmware (because of testing?). So what happens if I use a board with firmware developed in the pre-Windows 8/10 era?

Freshly Unboxed NXP FRDM-KL25Z Board

It might work, but the chances are high that the bootloader and firmware aren't ready for the "modern age," and as a result, the board might be bricked. If you still have a Windows 7 machine around (I do!), you are lucky. If not, then you need to read this article.

Outline

In this article, I describe how the OpenSDA (or any other virtual USB MSD bootloader or application) might be affected by Windows 8 and 10 machines. I describe a way to recover OpenSDA boards if the bootloader is not working or parts of the debug firmware have been erased or corrupted without the need for a Windows 7 machine or an external debug probe. I have created a video (also shown toward the end of this article) that goes through all the needed steps.

MSD Bootloaders

So we're in the year 2016 now, but a lot of software was developed years ago. What I have found difficult in working with all the different host systems (mainly Windows, but also Linux — I don't own a Mac) is that a new version of a host's operating system can add a lot of challenges. While everyone tries to prepare for the future, sometimes it is just hard. The Freescale (now NXP) OpenSDA and mbed bootloader present on all the FRDM (Freedom) and TWR (Tower) boards are no exception to this, with its MSD (Mass Storage Device) bootloader.

The MSD bootloader is actually a cool thing: The board enumerates on the host as a virtual USB memory stick. I can copy/send files to that 'virtual memory stick,' and it will program that file either to the board debug firmware or program the target application with it.

But the problem is that this 'virtual' MSD is not a full MSD: It only emulates the thumb/memory device without actually providing the full memory. So the bootloader or virtual MSD device tries to detect if I copy/transfer a firmware image (S19, binary, intel hex) file. Basically, the 'virtual' device intercepts write accesses and transforms them into something to program the microcontroller flash memory, either its own or the target device's.

However, the USB protocol is not simple and easy. Plus, developers test with the actual environment to do the job of the virtual MSD device. The problem is that newer operating systems (Windows 8, Windows 10, and others) tend to communicate with newly plugged-in devices much more than older operating systems. And these other accesses might confuse the virtual MSD device if they are not prepared for the extra chatter and communication. For example, virus scanners probe the device, or the operating system tries to index and catalog the memory device. Even worse, it might try to write all kinds of stuff and index files to the device. And this might confuse that virtual MSD device up to the point that the device either creates a buffer overflow or interprets an index file write as the application file and wrongly programs the device. Which can then brick the board.

OpenSDA Bootloader

This is a real problem. And it is not unique to one vendor or implementation. Both the Freescale OpenSDA V1 (see "FRDM Board Bootloader fails with Windows 8.1 Preview") and the mbed (OpenSDA V2.x) bootloader (see "How to Recover the OpenSDA V2.x Bootloader") are affected by this.

For OpenSDA V1, there is the workaround to update the bootloader with a Windows 7 machine (see "Illustrated Step-by-Step Instructions: Updating the Freescale Freedom Board Firmware"), and with this updated bootloader, things work well with Windows 8 and 10.

For OpenSDA V2, the consequences are much worse: the mbed bootloader needs to be reprogrammed with an external SWD/JTAG debug probe (see "How to Recover the OpenSDA V2.x Bootloader"), as that bootloader does not include an update mechanism.

No Windows 7?

But what if you do not have a Windows 7 (or XP) machine, and you do not have a debug probe? Then this article could help you, as it shows you a way to change a setting in Windows 8/10, which prevents Windows from writing things to the virtual MSD device.

I have verified the approach presented here on my Windows 10 (64bit) machine. I do not have a Windows 8 machine anymore (sorry), but I have no indication that the presented approach would not work on any 32bit/64bit Windows 8 and 10 machine.

Factory Firmware on Board

If you get a new board from the factory, you can check the firmware and bootloader on it.

Freshly Unboxed NXP FRDM-KL25Z Board

For example, the FRDM-KL25Z enumerates as FRDM-KL25Z device:

SDA Info File

Double-click on the info HTML file, and it shows the firmware version of that board:

OpenSDA Bootloader Version 1.09

So the above board reports the old V1.09 board is exposing the problem described in "FRDM Board Bootloader fails with Windows 8.1 Preview." Using a Windows 7 (do NOT do this with Windows 8 or 10!!!), I could update the bootloader to a newer version as outlined in "Illustrated Step-by-Step Instructions: Updating the Freescale Freedom Board Firmware."

Windows 8 and 10 Erases the Debugger Firmware in Bootloader Mode

It might not happen the first time when I enter BOOTLOADER mode (power the board with the reset button pressed), but with Windows 10, it happens after several tries: The board gets bricked, the debug application is erased, and I cannot debug the board anymore.

In normal mode, the small green LED nearby the OpenSDA K20 device is off. And in BOOTLOADER mode, the green LED blinks an error code (see video).

I have not found a list of error codes/blink codes. Does anyone have that?

I had cases where, for some reason, I was not able to re-enter BOOTLOADER mode again, but somehow, it started working again. If you are able to enter BOOTLOADER mode, then I can indeed see that the (debug) application on the board is erased:

Application Erased

Group Policy for Windows Search

Because the hot USB controller's extra accesses confuses the bootloader, the solution is getting rid of this extra communication. For me, this was caused by the Windows 'feature' of creating an index and library of all drives and files in the background to speed up searches. So, the solution is to turn this feature off.

Group Policy Editor: Disable Removable Devices from the Library Search

I can turn this 'feature' off with the Microsoft Windows Group Policy Editor (you might need administrative rights for this).

To launch the editor, use <Windows>+<R>, then launch  gpedit.msc.

Launching Group Policy Editor

This launches the management console. Dive down to Computer Configuration \ Administrative Templates \ Windows Components \ Search \ Do not allow locations on removable drives to be added to libraries. Enable that setting (which turns that feature off):

Local Group Policy Editor

With this enabled, the bootloader and debug/firmware loading works as expected with the Bootloader V1.09 as it comes originally on my FRDM-KL25Z board.

The following video shows the full process:

Summary

There are many boards shipped with firmware that is not able to deal with the latest host operating systems. So far, my recommended way was to use a Windows 7 machine to updated the bootloader on OpenSDA boards. Now, I have verified an approach that works for me without needing to update the bootloader or a Windows 7 machine. I still recommend updating the bootloader if possible, as this will prevent the OpenSDA V1 bootloader from being bricked with Windows 8 or 10 if in BOOTLOADER mode. For OpenSDA V2.x I recommend updating the bootloader with the new DAPLink (but this requires a debug probe, see "How to Recover the OpenSDA V2.x Bootloader").

Happy unbricking!