Recovering FRDM-K64F mbed Board

Posted on by

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 🙂

21 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

    Reply ↓

    • 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

      Reply ↓

  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

    Reply ↓

    • 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

      Reply ↓

  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

    Reply ↓

  7. 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

    Reply ↓

    • 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

      Reply ↓

      • 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

        Reply ↓

  8. 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

    Reply ↓

  10. Hi Erich,

    9/15/2020:

    I need your help with my new FRDM-K64F and P&E Multilink Universal.

    These were working find from inside MCUXpresso, debugging demo apps, Blinky & Bubble, with USB cable connected only to plain USB power port J22 on the FRDM.

    Using J22 USB port does not work for Hello World SDK project because that requires UART serial to USB TX/RX ports via the openSDA J26 port. So I asked PEmicro how to do it & they advised to drag-n-drop their DEBUG_OpenSDA_for_MBED_Bootloader_by_Pemicro_v108_v2.1.bin to the BOOTLOADER MSD, which I did after doing the SW1 press & hold on openSDA power up.

    The Windows Explorer pop-up was very brief & it goes away as soon as droped the .bin to it.

    PROBLEM: when I disconnect & reconnect the openSDA USB cable, BOTH the red & green LEDs are lit-up solid.

    My PC Device manager now lists the Jungo openSDA devices & Port COM5 Serial devices.

    However, inside MCUXpresso, the debug is not proceeding all the way even if I correctly select openSDA probes and such in the debug configuration.

    Then, to isolate the problem, I went back connecting USB cable to plain USB power port J22 just to be able to make BLINKY & BUBBLE projects to debug & run again. They too are now timing out & GDB is not launching anymore.

    Do you know what’s going on & can you help me resolve this matter?

    Thanks for your help.

    MI

    Like

    Reply ↓

    • Hi Ml,
      If the red LED is on, it means that the reset line of the K64F is going into reset all the time. It could be that you programmed an application to the K64F which constantly resets? In that case the OpenSDA might not be fast enough to halt the core as pointed out in this article. Are you able to use a normal debug probe on the J9 debug connector to program the K64F directly? I recommend doing that and flash a ‘good’ application to the K64F that way.
      I hope this helps,
      Erich

      Like

      Reply ↓

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.