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 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?

Freshly Unboxed NXP FRDM-KL25Z Board

Freshly Unboxed NXP FRDM-KL25Z Board

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/.

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 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.

MSD Bootloaders

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.

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 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.

Factor 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

Freshly Unboxed NXP FRDM-KL25Z Board

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

SDA Info File

SDA Info File

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

OpenSDA Bootloader Version 1.09

OpenSDA Bootloader Version 1.09

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:

OpenSDA LED Error Codes

OpenSDA LED Error Codes

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:

Application Erased

Application 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

gpedit.msc
Group Policy Editor

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

and enable that setting (which turns that feature off):

Local Group Policy Editor

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.

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

HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search

with the key “DisableRemovableDriveIndexing“. Run regedit (you need to have administrative rights) with <Windows>+<R> and “regedit”. Set “DisableRemovableDriveIndexing” to value 1:

Windows Registry

Windows Registry

Video

The following video shows how I bricked and unbricked a FRDM-KL25Z board:

Summary

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 πŸ™‚

Links

Advertisements

19 thoughts on “Bricking and Recovering OpenSDA Boards in Windows 8 and 10

  1. Erich,
    Thanks for this update. I somethimes use my heavy CAD machine to do a quick program while doing a board layout. It runs Win10 and that explains the 3 new Freedom boards that do not function any longer. Will have to try the above method.

    Like

  2. I tried this on Windows 10 Home and it would not update the firmware. I ended up successfully updating using an old XP laptop.

    Like

      • Hello Erich,

        I used an old 2012 Gateway desktop with Windows 10 home and searched the registry for DisableRemovableDriveIndexing which it found and I set the bit to 1. I dragged the v1.11 bootloader update file on to the controller which was showing BOOTLOADER. However, it never updated and stayed at v1.09. I also right clicked on the update file bringing up the dialog box and used “send to” copying that way but it didn’t work. I tried rebooting and power down but those had no effect. The v1.18 software also did not update. I thought the board might be bad so I dragged out an ancient HP Pavilion laptop with XP (that I forgot we still had at home – hadn’t powered up in 3 yars) and it flashed correctly.

        A few of us are using the KL25 for virtual pinball machines for a project started by Mike Roberts.

        https://developer.mbed.org/users/mjr/code/Pinscape_Controller/wiki/Homepage

        Thanks,

        Harry

        Like

  3. Hi Erich,
    on Windows 10 Home edition did not work for me too.
    GPedit.msc does not show the key you have signalled in the post and video too.
    Used the tool to localize the key in register: the path should be
    HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search
    But I can’t find Windows Search subdirectory!!!
    Found the key
    here:
    HKLM\SOFTWARE\Policies\Microsoft\PolicyManager\current\device\Search
    and there:
    HKLM\SOFTWARE\Policies\Microsoft\PolicyManager\default\Search
    set to 1 both fields but no change on bootloader behaviour (I have 1.10 version instead of 1.11 but it’s the same).
    😦

    Like

      • Hi Erich,
        your post is nearly perfect.
        I have just needed to add the key and its subkey.
        Thanks again

        Like

      • Unbelievable!
        First time it was ok (I have replied to you telling that!) then Windows started writing SystemVolumeInformation again!!!
        Entered Register key is as before.
        Of course FRDM board is no more working.
        LastStat.txt says “Programming” and no SDA application is in.
        Thanks the same
        πŸ˜₯

        Like

      • Hi Erich,
        together with register key modification you have posted, disabling Storsvc and WSearch services on my Win 10 Home, causes SystemVolumeInformation to be written with some delay (some tenth of seconds, quite enough to download bootloader 1.11).
        After that it’s like you have written: with bew bootloader version the board does not take care of SystemVolumeInformation.
        I have entered debug, plugged and unplugged the board several times.
        I think I can state it’s ok.
        Thank you very much

        Like

  4. Pingback: Reprogramming the Mikroelektronika Hexiwear Dockingstation | MCU on Eclipse

  5. This might sound rather outlandish but has it every occurred to you to simply use a Mac or Linux machine to upgrade it? Heck you could even simply boot a distribution from a USB stick on your high-end Windows 10 machine just for the upgrade of all your boards…

    Like

  6. 1) Thank you. After much searching and wringing of hands, this article provided the vital ah-ha about Win 10 corrupting the download file transfer. I have a FRDM-KV31F with Microboot 1.06 and Bootloader 1.12 that had a wiped out application (0.00). I hadn’t been able to upgrade it and then I lost the application. Now it’s upgraded to 1.20.
    2) I tried doing this on Win10 with a DisableRemovableDriveIndexing set to 1, but no success. I also tried doing it on a VirtualBox WinXP, but it wouldn’t properly recognize the FRDM-KV31F USB. Doing the download on the host Linux Mint OS is what finally worked. Perhaps the later bootloader now supports Linux.

    Like

    • I have seen a similar issue with corrupting the bootloader on Mac OS too, but not on Linux as I’m using that one not much. But the later bootloader had much better protection against the problem. On Windows 10 the issues dropped by factors, but I still see it once or twice during a semester with a classe of 30 or so students.

      Like

  7. Pingback: Recovering and Updating the NXP OpenSDA Bootloader with P&E Multilink and MCUXpresso IDE | MCU on Eclipse

  8. Pingback: Adding a Delay to the ARM DAPLink Bootloader | MCU on Eclipse

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s