Question about SWD interface protocol with K64F

[hokins]

Hi,

I have a question about SWD flash programming by using two different FRDMK64F boards, I use one of FRDMK64F board to verify my project but in some reason the MK64F chip is broken, so I bought a new MK64F chip to change it to the FRDMK64F board (named "board1"), and another FRDMK64F board used as backup solution (named "board2").

But I can not flash the FW code correctly by board1, and I checked the HW circuit was not shorted or damaged, so I checked the flash protocol with Logical Analyzer.

Then I found the difference in past steps. In step about read component ID register data, I got two different outcome:

"0x40030018"(board2) & "0x10150028"(board1).

next step, I used JLINK debug tool to connect & flash board1 directly (not using the MK20DX chip on board1), the FW was flashed successfully and worked like the board2.

The final verify step, I using Kinetis to write a sample blinky code and debug it with openOCD, then the amazing thing was happen, the FW was worked successfully, too.

is someone know what point cause the different behavior?

the attached file is the capture data by Logical analyzer(saleae)

Original Attachment has been moved to: board1_download_fw_FAIL.logicdata.zip

Original Attachment has been moved to: board2_download_fw_OK.logicdata.zip

Original Attachment has been moved to: fail.txt.zip

Original Attachment has been moved to: pass.txt.zip

[michael_galda]

Hi,

You have answered yourself. I remember the same case, when I was playing with this.

The OpenSDA onboard programming FW (in K20) is tied to the device ID originally placed on board.

So if you replace the main device on the board, the OpenSDA will not work.

We have discussed with PEmicro and board manufacturing team and the reason is that they want to protect their business with stand-alone programming tools. (not allow to use the on-board OpenSDA as the external programming tool for other devices)

thanks,

Michael

[hokins]

Hi Michael,

Thanks for your reply, so it means if I completed the development of my project on K64F board, then I already have a prototype hardware(not K64F), I need to using another debug tool (like JLINK or ULINK) to download FW directly, not using K20 mcu as fw download bridge.

[colin]

You can load the Segger J-Link OpenSDA firmware on the Freedom board OpenSDA K20 chip, and I understand the Segger OpenSDA firmware isn't tied to the serial number of the Freedom board target MCU.

Also you could gain even more freedom (no pun intended) by using the mbed K64F CMSIS-DAP OpenSDA firmware on the K20 chip instead, which unlike Segger and P&E's firmwares for OpenSDA, the mbed one is totally open and free -- you can use it to even debug other chips off-board if you install the 10-pin Cortex debug header.

[hokins]

Hi Colin,

I've tried to use the Segger J-Link OpenSDA firmware to trace & debug my target prototype & K64F board. And it simulated as J-link debug tool, too.

then I try it to flash fw to board1 & board2, It can't not complete the fw flashing.

then I checked the record of SWD output, the TRACE_SWD Pin & RST Pin trig some pulses then the fw flashing fail.

[michael_galda]

Yes, exactly, this is the correct approach

[Hui_Ma]

Hi

I use J-Link Commander tool to read two FRDM-K64F boards MDM-AP IDR value, which is not same for each board.

If the JTAG interface and on board OpenSDA debugger tool works with new mounted K64 product, that means the debug interface without any problem.

Then customer also could try a complicated application, such as Ethernet to check if other features working as expected.

Wish it helps.

Have a great day,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------