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 is written years from now because the inventory has not been updated, or because boards are still produced with that original firmware (because of testing?). So what happens if I use board with a firmware developed pre-Windows 8/10 area?
It might work, but chances are high that the bootloader and firmware is not 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….
UPDDATE: Be aware of the Bootloader Version!
There is one important aspect which showed up after I wrote the article below. The workaround presented below only works if the bootloader of the board has been already updated to V111 (BOOTUPDATEAPP_Pemicro_v111.SDA), see https://mcuoneclipse.com/2014/11/01/illustrated-step-by-step-instructions-updating-the-freescale-freedom-board-firmware/.
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 how to recover OpenSDA boards if the bootloader is not working or the parts of the debug firmware has been erased or corrupted, without the need for a Windows 7 machine or an external debug probe. I have created a video (towards the end of this article) which shows all the needed steps.
So we are in the year 2016 now, but still a lot of software has been developed years ago. What I have found difficult in working with all the different host systems (mainly Windows, but as well Linux (but still do not own a Mac machine 😦 ) is that a new version of a host operating system can add a lot of challenges. While everyone tries to prepare for the future, sometimes it is simply hard. The Freescale (now NXP) OpenSDA and mbed bootloader present on all the FRDM (Freedom) and TWR (Tower) boards is 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 one: 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 this into something to program the microcontroller flash memory, either its own or the one of the target device.
However, the USB protocol is not simple and easy. Plus the 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 kind 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 then can brick the board.
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 a way how to change a setting in Windows 8/10 which prevents Windows to write 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 any more (sorry), but I have no sign 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.
For example the FRDM-KL25Z enumerates as FRDM-KL25Z device:
Double click on the info HTML file and it shows the firmware version of that board:
So above board reports the old V1.09 board exposing the problem described in “FRDM Board Bootloader fails with Windows 8.1 Preview“. With 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 latest after several tries: the board gets bricked, the debug application erased and I cannot debug the board any more.
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).
The LED error codes are in section 3 of : http://www.nxp.com/files/32bit/doc/user_guide/OPENSDAUG.pdf:
I had cases where for some reasons I was not able to re-enter BOOTLOADER mode again, but somehow then it worked again. If you are able to enter the BOOTLOADER mode, then I can indeed see that the (debug) application on the board is erased:
Group Policy for Windows Search
Because the bootloader is confused by the extra accesses of the host USB controller, the solution is to turn this extra communication. For me this was caused by the Windows ‘feature’ to create an index and library of all drives and files in the background to speed up search. 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).
💡 It seems that the Group Policy Editor is available in Windows 10 Pro Edition, and *not* part of the ‘Home’ edition. See below for doing the same directly in the registry.
To launch the editor, use <Windows>+<R>, then type launch
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
and enable that setting (which turns that feature off):
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.
Using Windows Registry
After writing this article, I have found out that the ‘home’ edition does not include that group policy editor. I used this group policy search tool to search for “Do not allow locations on removable drives to be added to libraries” registry key: it is under
with the key “DisableRemovableDriveIndexing“. Run regedit (you need to have administrative rights) with <Windows>+<R> and “regedit”. Set “DisableRemovableDriveIndexing” to value 1:
The following video shows how I bricked and unbricked a FRDM-KL25Z board:
There are many boards shipped with firmware which 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 which works for me without the need to update the bootloader or a Windows 7 machine. I still recommend to update the bootloader if possible as this will prevent the OpenSDA V1 bootloader to be bricked with Windows 8 or 10 if in BOOTLOADER mode. For OpenSDA V2.x I recommend to update the bootloader with the new DAPLink (but this requires a debug probe!, see “How to Recover the OpenSDA V2.x Bootloader“).
Happy Unbricking 🙂
- Microsoft community post about group policy settings: http://answers.microsoft.com/en-us/windows/forum/windows8_1-hardware/how-do-i-prevent-system-volume-information-files/815b0046-d631-4419-a43e-44083a3733f5?auth=1
- How to Recover the OpenSDA V2.x Bootloader
- Illustrated Step-by-Step Instructions: Updating the Freescale Freedom Board Firmware
- New P&E OpenSDA Firmware v114