Windows 8 and 10 have added a ‘feature’ to scan and index devices attached to the host machine. This means that bootloaders or MSD (Mass Storage Device) programming implementations on evaluation boards developed in the Windows 7 age might not be prepared for that. Up to the point that it can impact the bootloader as outlined in “Bricking and Recovering OpenSDA Boards in Windows 8 and 10“. So far one of the easiest way to get out that situation was to use a Windows 7 machine. But if you only have a Windows 10 machine available, this article describes the needed steps to update the bootloader with Windows 10 host machines.
The ARM mbed USB MSD bootloader which is used on many silicon vendor boards has a big problem: it is vulnerable to operating systems like Windows 10 which can brick your board (see “Bricking and Recovering OpenSDA Boards in Windows 8 and 10“). To recover the board, typically a JTAG/SWD programmer has to be used. I have described in articles (see links section) how to recover from that situation, including using an inofficial new bootloader which (mostly) solves the problem. The good news is that ARM (mbed) has released an official and fixed bootloader. The bad news is that this bootloader does not work on every board because of a timing issue: the bootloader mostly enters bootloader mode instated executing the application.
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
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….
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.
FRDM-K64F (top) programming the OpenSDA Bootloader (bottom)
Sometimes it is very convenient to load a new firmware to a board without the need for a hardware debugger. This is usually done with a bootloader. The NXP Freedom and Tower evaluation boards have on-board debug device/microcontroller (OpenSDA) which can load different firmware implementations like CMSIS-DAP/mbed, P&E Multilink or a Segger J-Link OpenSDA applications. Both mbed and P&E implemenations support to program the board with drag&drop: simply send a file to a virtual MSD (Mass Storage Device) to get it programmed. The latest Segger OpenSDA firmware has this ability added now too: Programming the board with a virtual MSD device:
FreeRTOS is probably the number one RTOS used, and Eclipse is likely the most popular IDE I can think of. But debugging FreeRTOS applications with Eclipse and GDB is somewhat limited? What I would like to get at the minimum is this: ability to see all the different threads in the Eclipse debug view like this:
FreeRTOS Threads in Eclipse with OpenOCD
As you might guess from that screenshot: this post is about how to make FreeRTOS tread debugging possible with Eclipse and GDB :-).
Many times it is very useful to debug multiple boards at the same time. For example if I’m debugging a communication stack between two boards: that way I can debug the protocol on both sides. Eclipse is a great framework which allows that. This post shows how to debug multiple boards (e.g. the NXP Freedom boards) in parallel from the same Eclipse IDE using GDB and the Segger J-Link:
In one of my earlier posts (“Using the DHT11/DHT22 Temperature/Humidity Sensor with a FRDM Board“) I’m using the DHT11/DHT22 temperature/humidity sensors with the FRDM-KL25Z board. These sensors are very inexpensive, but have limited measurement range and accuracy. As pointed out by a reader of that article, Sensirion (a Swiss company :-)) has good sensors too, and I decided I would like to try the SHT11 sensor:
For my RNet stack I need a way to identify nodes in the network using a unique address. What I need is Media-Access (MAC) address. Base on such a unique address I can assign short addresses (e.g. with a DHCP or similar protocol to automatically assign shorter network addresses). So how to uniquely identify my network nodes?
The Freescale Kinetis microcontroller have nice feature: they have a Unique Identification Register (UID) which would be a perfect fit for a MAC address :-).
Microsoft has released the Windows 8.1 Preview. So you can try out the next update of Windows 8. In short: Do NOT use Windows 8.1 Preview if you are using a Freescale FRDM board! Otherwise you will not be able to change the OpenSDA firmware (MSD or debug application).
❗ Update: P&E has released a new firmware v114 which combines USB CDC, MSD bootloader and debug application, and this firmware fixes the issue described in this post.
Well, I have not used it personally: I never use ‘test’ or ‘preview’ versions on my ‘production’ machine. It is ok to try things out on separate ‘scratch’ machines, but not on something I need to have stable for my work. Well, some of the students in my INTRO class were not able to resist and downloaded and installed Windows 8.1 Preview on their machines. With the result that the OpenSDA Bootloader does not work with Windows 8.1 Preview:
❗ It seems that the problem exists as well with the Windows 8.1 ‘final’ release.