FRDM-K64F as external target programming interface with OpenSDA/DAPLink

[martinmignone]

Hello to the community.

The situation is as follows:

Objetive: flash program a custom board with MK20DX256VLL7 Kinetis Microcontroller.

Resource: FRDM-K64F using the MSD drag&drop DAPLink application with OpenSDA V2 (with the hardware modifications to allow external target programming already done).

The FRDM-K64F succcesfully programmed an external K64FN1M0VLL12 in a custom board with an image file (.bin) generated in KDS V3.0 with KSDK V1.2, so the OpenSDA and DAPLink application is working well.

The problem is when I try to program the K20 mentioned above. After I copy the .bin image for the K20, the DAPLink unmount y re-mounts itself with a FAIL.TXT file, which contains the following sentence: FLASH algorithm write command FAILURE. I tried generating the ".bin" file for the K20 in many different ways, using Code Warrior 10.5, using KDS 3.0, elf/hex to bin converter tools, etc: nothing seems to work, always the same error.

I have tried with other versions of the OpenSDA too, with no luck.

So, here the questions:

1) Have anyone achieve to program an external K20 target using OpenSDA/DAPLink with a FRDM-K64F board? If the answer is yes, how do you proceed?

2) Does the OpenSDA/DAPLink support flash programming a K20DX256VLL7 microcontroller? Where can i find a list of supported devices?

Any help will be appreciated.

Regards,

Martin Mignone

[BlackNight]

Hi Martin,

you might have a read at Using the Freedom Board as SWD Programmer | MCU on Eclipse  which gives some details how it works. If you want to use the MSD (Drag&Drop) programmer mode, then the device attached on the debug cable has to match *exactly* what OpenSDA MSD firmware you have loaded. The reason is that even inside the same family, the flash size, location and algos to be used are different.

As another point: to my knowledge the MSD programming will degrade after some number (I think around 64) of programming through MSD. So that solution is anyway not recommended for a larger series of programming.

What is your motivation to use the K64F board for this? Because of the MSD functionality or because of a 'free' board? If it is about the later, then what I would recommend is maybe to look at the SEGGER J-Link EDU Mini (https://www.mouser.ch/ProductDetail/Segger-Microcontroller/80891?qs=sGAEpiMZZMve4%2fbfQkoj%252bGJy0R... ) which costs only $20 and is targeting any non-commercial or educational/hobby work.

I hope this helps,

Erich

[martinmignone]

Dear Erich,

Thank you very much for your answer and for all your posts in MCU on Eclipse, they are extremely useful and has saved me more than once!!!

Answering your question, my motivation to use a FRDM board as a programmer using OpenSDA/DAPLink is for the production sector, because it doesn´t require any additional software on the host PC, just a USB port and a ".bin" file, and above all, it doesn´t require any configuration or options to be set, it´s just drag&drop. Besides, we are using the FRDM64K in many products so it´s a common item and we have a bunch of them.

However, i wasn´t aware of this: "As another point: to my knowledge the MSD programming will degrade after some number (I think around 64) of programming through MSD. So that solution is anyway not recommended for a larger series of programming". What is the cause of this "degradation"? This means that if I use the FRDM board as a programmer, after a long series of programming, the K20 (OpenSDA) of the board becomes useless? Is this specified somewhere?

In the mean time, I have tried using USBDM on the FRDM boards to accomplish the same: program off-board targets. It seems to work well so far, but the downside is that requieres specific software & drivers installed on the host PC. Do you know if the USBDM has the same problem of degradation? I would be nice to know in advanced if it has the same issue, because i would no longer continue with that line if it is!!!

I´m aware that the ultimate solution is to buy a programmer designed exactly to do that, such as the Cyclone from P&E micro, but i´m not sure if it meets the budget plans!!!

Thanks in advanced.

Regards,

Martin Mignone

[BlackNight]

Hi Martin,

that degradation to my knowledge only applies to the OpenSDA v1.x using the MSD programming mode. I learned about this in my early days of OpenSDA, and basically it increases the programming time. So I was still able to use it, but it was maybe half as fast. I have not verified if this still exists as now I rarely use that MSD mode.

About your motivation using the MSD programming: If you really care about what you put into the field, then I recommend that you buy a Cyclone from P&E or a J-Link Flasher (Flashing many ARM Boards without a Host PC | MCU on Eclipse). The thing is that programming a device for development/debugging might not use the same rigid (and verified) flash programming timing/algos as used for production units. That's why usually these devices have a premium price points. From my own experience we had issues in the field with devices programmed with normal 'debugging' tools. Using dedicated programming devices like the ones above solved that problem. It is all about: how much failure in the field can you afford? Just my $1 cent.

I hope this helps,

Erich

[martinmignone]

Hi Erich,

I will take it account very carefully your last question about the amount of affordable failures in the field...there is a lot involved there :smileygrin:

Is there any known issues related to this degradation with newer versions of the OpenSDA v2.x or with the USBDM? 

Thanks for your reply!!!

Regards,

Martin Mignone

[BlackNight]

HI Martin,

I have found that one using the OpenSDA v1 with FRDM-KL25Z. I have not verified this for any other board/firmware as I did not use MSD much at all after that. As it was with the P&E OpenSDA implementation, this should not be an issue with USBDM at all. If you really want to know for OpenSDA v2, I suggest you would need to try it out. It very well could not exist there.

I hope this helps,

Erich

[martinmignone]

Erich,

I would give it a try and will let you know how well or bad it works after a long term run! :smileygrin:

Thank you very much for all the help provided!!!

Best regards,

Martin Mignone

[tsi-chung_liew]

Martin,

The MSD feature of Daplink on the FRDM-K64F is for K64 flash device. The flash algorithm built in the Daplink is not suitable for MK20DX256VLL7, it could be sector size, command, etc are different. The debugging feature is able to use via daplink because the flash algorithm in on the IDE.

If you need MK20DX256VLL7 support, you need to find similar board with daplink and program (drag-n-drop the app) on FRDM-K64F CMSIS-DAP bootloader if both bootloader version are the same, or the application start address (0x5000).

Regards,

TsiChung

[martinmignone]

Dear TsiChung,

Thank you very much for your answer.

So, just to clarify and summarize, this means that no matter which OpenSDA/DAPLink version I´m using in the FRDM board, i won´t be able to program an external target that isn´t exactly of the same family of the on-board target of the FRDM board.

I too own a FRDM-K20D50M, and tried to do the same thing, with no luck, and the external target in my custom board (MK20DX256Vll7) is within the same family of the on-board target of that FRDM (at least the K20 part, not equal in frequency and memory). Don´t know why this doesn´t work either.

Thanks in advanced.

Regards,

Martin Mignone