Recovering Serial Connection on FRDM-LS1012A

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 OpenSDA firmware running on this controller not only allows the serial connection to be passed over UART but also allows JTAG debugging over the CMSIS-DAP 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 MBED.

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 post having a 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.