During a recent workshop, I observed a strange interaction between Windows 10 systems and the serial connection to an NXP Freedom LS1012A board already referenced in one of my previous posts (Bootstraping Debian 9 (Stretch) for arm64). Due to this interaction two boards were rendered useless during the workshop.
This post explains the problem and shows how to easily recover the boards with the matching firmware for the serial to USB converter.
The workshop was delivered with a prepared virtual machine running on
the participants laptops. As I have done such workshops a dozen
times, I have a fairly good idea of the potential problems and how to
overcome them. Usually the installation of the VM and VirtualBox is
straightforward and the most difficult part is to get the network
connection to work in bridged mode on the wired Ethernet adapter.
This setup is required so the target board can request tftp and NFS
services from the VM as the default
NAT mode only allows
connections originating on the VM. Assigning the serial console
running over USB to the virtual machine also has some potential for
problems but worked pretty well recently so on this occasion I did not
expect a lot of trouble.
Potential problems with newer versions of Windows wasn't at all on my
radar as a lot of IT departments still run company machines on
Windows 7. A lot of time was lost watching the few participants with
Windows 10 machines rendering their target boards useless. As
analysis shows, the origin of the problem is the choice of NXP of
converting the SoCs UART to a USB connection. On most embedded boards
there is a separate chip responsible for this. Especially FTDI chips
proved to be a good choice as they work solidly and without an
additional driver on popular operating systems. NXP however chose to
use one of their Kinetis Cortex-M4
micro controllers for this task on many of their evaluation
boards. The FRDM-LS1012A specifically has a K20DX128 populated. The
firmware running on this controller not only allows the serial
connection to be passed over UART but also allows JTAG debugging over
functionality developed for the Arm Mbed
project. As a bonus, the micro-controller also presents itself as a
mass storage device to the host. Simply copying a new (working)
firmware file to this storage device is enough to update the firmware.
Usually this device pops up automatically in most OSes labelled
Once the FRDM-LS1012A board was connected to a Windows 10 machine in
the workshop, a file explorer window showing the MBED drive popped up
as expected but immediately closed itself again. This procedure kept
repeating itself with only a few seconds of pause. Influencing it with
the mouse or keyboard was simply not possible and as the system became
uncontrollable, the board was disconnected after some tens of
iterations. Exactly how often the board was connected to the host
system and how often the explorer windows showed before the boards
became unusable is not completely clear to me, but in the end the
boards got into a state where they showed life only by pressing the
reset button. Following this they presented a storage device labelled
BOOTLOADER instead of the expected
MBED. Also there was no
serial connection offered anymore. After the workshop I was left with
two such supposedly dead boards.
Research during the next day quickly showed that other people also
experienced such problems on varying OpenSDA systems.
There is a thread even on the NXP forum about this, so at least
this explained my own experiences. The real difficulty was to find
the specific firmware file needed to recover the FRDM-LS1012A boards.
With some help from NXP I was finally pointed to another NXP forum
k20.zip file attachment. The archive not only contains
short instructions but two firmware files and a list of applicable NXP
evaluation systems. According to this list, the
k20dx128_if_mbed.bin file (available here for your convenience) should fix the
problem. And sure enough, simply copying it to the mass storage
device is all that is needed. Wait for the LED to stop flashing and
re-plug the board to make everything work again.