Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Recovering the FRDM-K64F Bootloader, or: Cloning the Program of a Microcontroller

DZone's Guide to

Recovering the FRDM-K64F Bootloader, or: Cloning the Program of a Microcontroller

· IoT Zone
Free Resource

Address your IoT software testing needs – improve quality, security, safety, and compliance across the development lifecycle.

The Freescale FRDM-K64F and FRDM-K22F have a different OpenSDA (v2) firmware on it: unlike the earlier (v1), that firmware is open and not protected which is a great thing. However, it has the disadvantage if you use the wrong SWD/JTAG header on your board, the bootloader on the K20 OpenSDA microcontroller is gone :-(

Two SWD Headers on FRDM-K64F Board

Two SWD Headers on FRDM-K64F Board

This happened to a student who did not pay enough attention which programming header to use (I admit: it could have happened to me too). So how to recover the bootloader on that board? I checked the Freescale Freedom board pages, but there is no bootloader binary or project to download :-(. But I had another board: why not copy that firmware to recover the firmware on the other board?

  1. Retrieve the image of a working board
  2. Program it to the broken board

:idea: If you do not have a second board with a good firmware on it: don’t worry and read the summary at the end.

I’m using here a Segger J-Link with Kinetis Design Studio, but same steps should be applicable for other debug connections or IDE too, with the same principle.

:!: The steps here work only for the new OpenSDA v2 boards (e.g. FRDM-K64F), and not for the previous ones (e.g. FRDM-KL25Z).

Project for K20DX128

MK20DX128 OpenSDA Device on FRDM-KL25Z

MK20DX128 OpenSDA Device on FRDM-KL25Z

First I create a project for the OpenSDA device present on the board, which is a Kinetis K20DX128:

Project to Program the K20DX128

Project to Program the K20DX128

This project allows me to write normal applications for the K20, and I can use to copy and past firmware files between boards.

Attach Debug Configuration

For that project, I’m creating an ‘attach’ configuration: I want the debugger to connect to a working board, without changing the board content. With the Segger debug configuration I use the following settings:

In the debugger tab, I specify the microcontroller:

Debugger Attach Configuration (Segger)

Debugger Attach Configuration (Segger)

The most important setting is in the ‘Startup’ tab: here I need to disable ‘Load Executable':

Debugger Attach Startup Configuration

Debugger Attach Startup Configuration

The other settings (breakpoint setting, continue) are more optional.

:!: There is a known issue with the Segger connection that somehow a  true ‘attach’ to the target is not working (attaching means that the target keeps running as normal). What happens is that after connection, the Segger J-Link will reset the target, even with ‘Pre-run reset and halt’ disabled. I have found a solution for this, but it does not matter in this use case.

Grabbing the Firmware

With this ‘attach’ configuration, I ‘debug’ now the K20 of my working board.

Grabbing Firmware from the Board

Grabbing Firmware from the Board

Because I don’t download anything, that firmware is not touched. It resets to the bootloader vector table:

Stopped Bootloader

Stopped Bootloader

Now I use the Memory view to add a new memory monitor, starting at address 0x0:

Added Memory Monitor

Added Memory Monitor

Then export the memory (see “Memory is everything“):

Exporting Memory from Memory View

Exporting Memory from Memory View

I use the S19 file format (see “S-Record, Intel Hex and Binary Files“), and specify the memory I want to dump:

Dumping the Memory as S19 File

Dumping the Memory as S19 File

For the bootloader, only the first 16KByte (or better 64 KByte) would be necessary, but I’m free to dump the memory. If I dump the full memory, then I have not only the bootloader, but as well the application loaded on the K20.

Exporting the memory will take a few seconds to complete. Then terminate the debug session. Now I have an image copy of what is on the working K20. In the next step I’m going to program it on my broken board.

Copy the Firmware to the Other Board

To program the firmware to the other board, I create again a launch configuration. This is a normal configuration, but instead the normal application file, I specify the S19 file I just have copied from the previous board:

Using dumped file to program to other board

Using dumped file to program to other board

And with this, I debug/download/program my broken board:

Copy of the Firmware to the broken board

Copy of the Firmware to the broken board

and indeed, I have a bootloader again :-) :-) :-)

Summary

The bootloader on the new FRDM boards (FRDM-K64F, FRDM-K22F) is not protected which is a good thing. But in case the bootloader is corrupted, I need a way to restore it. One way I have shown in this article is to clone and copy the bootloader (and the application, if you want) from an existing board. That method is of course handy as well if you want to program multiple boards with the same S-Record file too. Or if you want to make a backup of a firmware on a board.

The only problem is: what if you have destroyed the firmware on your board, and you do not have a second board? I only have found out after writing this article that indeed Freescale has attached the bootloader binary at the end of this community post: https://community.freescale.com/docs/DOC-100720. Grab that .afx (it is infact an .elf file) file and program it instead of the .s19 file :-).

Happy Recovering

Accelerate the delivery of high-quality software in the connected IoT era through an integrated analysis, testing, security, and analytics platform. Parasoft's comprehensive portfolio of testing toolsautomates time-consuming testing tasks and provides management with intelligent analytics and reporting so they can focus on what matters.

Topics:

Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}