Recovering FRDM-K64F mbed Board

The mbed for FRDM-K64F firmware (http://mbed.org/handbook/Firmware-FRDM-K64F) has great potential. Unfortunately it seems that edges are still very rough: It happens very  often that my FRDM-K64F board gets locked up :-(. I can see that the target CPU is constantly resetting: the red reset LED is always on:

FRDM-K64F Red Reset LED always on

FRDM-K64F Red Reset LED always on

That alone would not be bad, but OpenOCD is not able to connect to the CPU any more:

CMSIS-DAP and OpenOCD not able to connect to the board any more

CMSIS-DAP and OpenOCD not able to connect to the board any more

What now? Well, for such cases I have a P&E Multilink or Segger J-Link on my bench to get directly control over the running wild CPU:

J-Link Hooked Up to recover the K64F

J-Link Hooked Up to recover the K64F

Usually this works well, but with the mbed firmware on the Kinetis K20 of the FRDM-K64F board, this does not help: even the Segger J-Link had to give up:

Segger J-Link gives up

Segger J-Link gives up

The mbed debug application constantly resets the core. Even worse, sometimes the green J-Link LED turns red all the time too :-(.

Segger J-Link LED turns red

Segger J-Link LED turns red

What now? I have found two ways to recover from such a situation:

Workaround 1: Copy a ‘recovery’ binary file

It seems that the mbed bootloader is able to recover the Cpu if it programs a ‘good’ program with the MSD (Mass Storage Device) bootloader. For this, e.g. download the http://mbed.org/media/uploads/sam_grove/helloworld_k64f.bin and copy it to the MBED disk drive. That should get things under control again.

Workaround 2: Turn off K20 microcontroller running mbed Bootloader

Because it seems that the Kinetis K20 with the mbed debug application is interfering, the solution is to remove power from the K20. For this, instead powering the board through the OpenSDA connector, I power the board with the K64F USB connector:

Power the FRDM-K64F Board with other USB connector

Power the FRDM-K64F Board with other USB connector

Then I use the external debug cable to regain control of the K64F. After that I can re-power the K20.

Summary

The mbed bootloader and CMSIS-DAP application is not very stable (yet), so it could happen that downloading using CMSIS-DAP causes the processor and board to constantly reset, to the point that normal debugging is not possible any more. One solution is (if the mbed bootloader is still active) to copy a dummy file so the K64F gets reprogrammed trough the bootloader. The other approach is to remove power from the K20, and then connect and flash the K64F with an external debug cable.

Happy Recovering 🙂

Advertisements

17 thoughts on “Recovering FRDM-K64F mbed Board

  1. Hello Erich, is this mbed cmsis-dap interface issue or KDS openOCD, or official openOCD ? You have not stated how did you manage to lock the chip. Using flashing a binary or openocd? Can I reproduce this? If this issue is cmsis dap related, report it to the oficiall cmsis dap repo. we can look at it. I guess this will be openOCD related. I have been using k64f with uvision for quite a while, without any issues.

    Regards,
    0xc0170

    Like

    • Hi 0xc0170,
      To me, this is a fundamental issue of the mbed CMSIS-DAP implementation: It is easily reproduced with a .BIN file which does not have the FLASH configuration bits set. I’ll send you by email my example. What happens is that if you miss to set the FLASH configuration bits in your application, the K64F resets, and in combination of the mbed CMSIS-DAP the chip gets unrecoverable by CMSIS-DAP. You will see what I have described in this post. You might consider that not programmign the FLASH configuration is a user error, but such a user error is easily made, and such a small oversight by the user shall not block/brick a board. Moreover, that I do *not* see the issue with using the original OpenSDAv1 (Keil) CMSIS-DAP, the P&E Multilink and the Segger J-Link: they all have the safety net implemented and their flash programming prevents that the board gets into that state: I think the same needs to be done by the CMSIS-DAP of mbed?

      Like

  2. Pingback: Binary Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins | MCU on Eclipse

  3. Pingback: Segger J-Link Firmware for OpenSDAv2 | MCU on Eclipse

  4. Hello Erich, I think another workaround would be installing openSDA SCK jumper and cut bottom shorting trace, so you will be able to disconnect/connect openSDA link.

    Like

    • Hi Rafael,
      yes, that should work as well, as it disconnects the OpenSDA from the target processor.
      But it might be necessary as well to disconnect the reset line to the microprocessor, as I have seen that if the OpenSDA constantly resets the processor, it is hard to regain access to it.

      Like

  5. Hi Erich, I do not have a Segger J-Link or a P&E Multilink.
    Copying any .bin files to the MBED drive creates always a fail.txt file:
    NOT CONSECUTIVE SECTORS
    I tried everything under Win7,Linux,Mac, KDS1.1.0/1 and with mbed.
    Will be the last chance to purchase an external JTAG device?
    Regards, Joerg

    Like

  6. Hi Erich, i was working on the k64f and trying to use the USB CDC in my program, i was working with Processor Expert components using your latest release, but the USB connection couldn’t be recognized by mi pc, the device manager reported “unknown usb device(device descriptor request failed)” so i thought about the issue with the MPU and disabled it manually in my main writing a line above the PE_init(), but the problem persisted, I pressed the “Terminate” button but the debugging session was still active so i disconnected the board but then, when i tried to debbug again, my board was locked/bricked with the problem of the reset led that happens every time i try to debug any program. I use the J-Link OpenSDA 2 firmware. I have already loaded the bin file of this post (with the bootloader mode active) but when i connect again the USB SDA, mi board appears to be dead, no led is on and no device is recognized in my device manager. The only thing i can do to get my board active again is loading the J-Link OpenSDA 2 firmware again but the problem with the red led still persists. I don’t have an external debugger. Is there an alternative?

    Like

    • Hi Adrian,
      are you using Windows 10? I have seen recently some cases where Windows 10 somehow is able to erase the openSDA debug application on the K20.
      As for the K64F USB CDC: are you using my example project? Can you try that one if this works for you. That example project properly disables the MPU and should work out of the box.
      I hope this helps,
      Erich

      Like

      • Yes, Windows 10. I didn’t use your example project for the K64F i only used your example code and added the MPU disabling.

        Like

  7. Thanks for sharing valuable information.

    I have one question, I am using FRDM-KW40Z board. But unfortunately when I plug this board into windows 10 based machine the bootloader is gets currupt. And then board I can’t detect my board. Even I tried with hold reset button and then plug USB cable but no success.

    Do you have any idea how to recover boad? Or how to download new bootloader in openSDA.

    Please suggest me any external debugger/programmer which can reprogram bootloader in openSDA. So my board can start as normal.

    Thanks in advance

    Like

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