recovering K20 on FRDM-K64F

[tselmeci]

Hello!

Accidentally I've wrecked my FRDM-K64F totally during playing with J-Link Lite CortexM JTAG probe. The situation is so bad that connecting the USB to the OpenSDA interface neither any LED lights up, nor appears the device as MSD (even if I keep the reset button pressed during power on).

I haven't found any usable information on recovering the K20 from scratch (every article is only about changing the application in K20, so that it's possible to switch between OpenSDA1/2 etc.). It appears the bootloader itself is broken. Can I somehow fix it by using J-Link Lite? I'm using linux and the command line tool JLinkExe.

Thanks,

[BlackNight]

It looks the K20 on the FRDM-K64F is locked up, maybe? Or is it the K64Fdevice?

I have seen cases where the K64F was locked up: using a special S19 file sent othe K20 solved that for me.

If the K20 is screwed up (somehow?), then you might need to re-flash the K20 with an S19 file.

For this you will need a SWD/JTAG programming device: either another FRDM board, or a J-Link (lite).

Do you know which micrcontroller is the problem? Maybe your board is damaged too.

Erich

[tselmeci]

I believe the K20 is locked up, since it refuses to appear as USB device whatever I do.

I want to learn how to burn programs directly to K64F with J-Link. I think these were the mistakes I've made:

-1) connected the JTAG cable to J10 (SDA), which is wired to K20 instead of K64F;

-2) performed 'erase' command in JLinkExe, which cleared the entire flash. As I see in the MCU documentation (and as I saw in objdump information), the executables in the flash shall be loaded at 0x410 instead of 0x00 to avoid overwriting the flash configuration fields;

Even if I can't recover this FRDM-K64F, it'd be really useful to know how to use J-Link to burn my programs directly (without playing with the MSD etc), especially because we have a custom board without K20, so only JTAG is available...

[BlackNight]

There is the following site

OpenSDA Serial and Debug Adapter|Freescale

which hosts firmware files for your board: select your board, and you can downlod the binary for the K20, then program it with your J-Link?

Erich

[tselmeci]

I haven't found the correct firmware for my board. I can only find the 'interface' (or application) binaries everywhere.

The mbedmicro/CMSIS-DAP ( mbedmicro/CMSIS-DAP · GitHub​ ) appears to be the one which can be used to compile the bootloader, but I've got no ARMCC (non-free) and haven't found any precompiled bootloader.

This is the J-Link script I use:

si 0

speed 100

device MK20DX128xxx5

r

h

sleep 500

unlock Kinetis

erase

sleep 500

loadbin bl.bin, 0x410

exit

[tselmeci]

I've got a file named '0221_k20dx128_k64f_0x5000.bin'. I view it with dhex. It appears that until 0x400 there are default interrupts vectors, from 0x400-0x40F the flash information area and then a lot of code. So for this case I'd need the 'loadbin bl.bin, 0' command. But the K20 is still silent... Maybe I'll try to copy the K20 flash contents of our other FRDM-K64F to this device...

[tselmeci · Accepted solution]

Alright, I've figured it out.

I've dumped the working K20's flash contents and compared with the broken one. My suspicion was right, none of the files I've found on the internet is the K20 bootloader itself, instead they're the interface (application) codes implementing OpenSDAv1/2/etc according to your selection.

The interface code begins at flash address 0x5000, while the bootloader at 0x0000. I took out the bootloader code from the working K20. After burning the bootloader code to the bad K20 it immediately became operational when I held the reset button during power up. And from this point on it was easy to upload any kind of interface code.

I'm attaching a small script which rewrites the K20 bootloader. Everybody shall use the script on his own responsibility. And don't forget to attach your JTAG cable to J10. I'm not publishing the bootloader code itself, because I'm not aware of its licensing...

si 0

speed 100

device MK20DX128xxx5

r

h

sleep 500

unlock Kinetis

erase

sleep 500

loadbin k20-bootloader.bin, 0

r

exit

[TodorTodorov]

Hi,

I did the same mistake and erased my entire K20 chip - with the bootloader. Unfortunately for me, I do not have another board, from which I can extract a working one, and haven't found any on the internet either. There is one here in the communities, at the bottom of the OpenSDAv2 page, but when I flashed it, Windows refused to recognize it and there is no emulated flash drive...

Would it be possible to post your working k20-bootloader.bin, with which you had success?

Thanks!

[BlackNight]

Hi Todor,

have a look here Recovering the FRDM-K64F Bootloader, or: Cloning the Program of a Microcontroller | MCU on Eclipse  and here KDS/FRDM-K64F120M/FRDM-K64F_Bootloader_Recovery .

I hope this helps,

Erich

[TodorTodorov]

Hello Erich!

Thank you for your reply. Let me first say, that your blog is one of my go-to resources and I enjoy reading it, even when I don't try out everything that you share... Consequently, I first tried to fix it using your suggestion for bootloader recovery, the download of the original bootloader from the OpenSDAv2 page here on Freescale/NXP, and the flashing through Eclipse after J-Flash Lite could not circumvent the bootloader region lock.

No luck. Turns out, the bootloader is just fine and the fault is with Windows 10. My problem seems to be the dreaded USB connect/disconnect issue, that Microsoft cannot seem to get right.

I had not worked with my FRDM-K64F since I upgraded to Windows 10, and yesterday was the first time I did it. What I noticed immediately was that the MBED usb drive detached and re-attached itself very frequently without any user activity - that's the reason why I assumed that the firmware in the MK20DX was corrupt. Sometimes it would refuse to save a bin file at all, sometimes the copy process would finish without errors but nothing would happen on power-cycling the devboard. So up I went and erased the chip, trying to re-flash the bootloader and the K64F interface.

In the end I downloaded MDK5, installed the v4 legacy support, recompiled the bootloader from Git, and re-flashed everything directly from the Keil IDE. The result was the same as at the very beginning of the ordeal. I also tried SEGGER's own OpenSDAv2 firmware, with the same result. So I used my wife's laptop running Windows 7, and everything worked just fine - the USB drive emulation, dropping a bin file and programming, executing the app from the K64F flash on power cycle. Interestingly, I then reattached the already programmed board back to the Windows 10 host and it failed to execute. I suspect that since the bootloader and the OpenSDAv2 firmware do not work well with Windows 10, all this connect/disconnect activity is making the MK20DX128 to keep the main CPU in reset state. Some threads on the mbed Developer site point to a possible race condition in the Windows USB init routines, which is sending spurious USB bus reset signal to the dev-board.