I'm trying to get my TWR-K65F180M module running.
I was not able to select the OpenSDA-Debugger in the KDS Debug Settings.
I also was not able to use a external debugger with the board. Even after disconnecting the J32 jumper to disconnect the OpenSDA on-board debugger.
What am I missing?
Did you ever get the OpenSDA connection working on your TWR-K65F180M? I have the same board version (700-28036 Rev A and SCH-28036 Rev D) as yourself with what looks to be a very similar problem. I started a thread about it here:
TWR-K65F180M board unintentionally secured
Peter can you remember exactly what you did to get the above binary to work? I've tried it but it's as though the TWR-K65F180M is incapable of changing its mode from MSD. As it seemed to take more than one go I'm wondering if there's something to be aware of to get it to work?
There are at least 3 different versions of OpenSDA. I was able to get the P&E firmware version of OpenSDA (v1.0 I think) to work with the K20-based bootloader/debugger connection on the K65 board. I had to get the Windows-side driver from
I also needed to replace the K20 bootloader driver; this is described at
When it works properly, the board shows up as a USB drive named BOOTLOADER.
Then, previous attempts to use the debugger left 'zombie' processes running: see my earlier post in this thread.
I tried but I was never able to get OpenSDAv2.0 or OpenSDAv2.1 working.
I then temporarily configured the K65 board to bypass the K20 bootloader (by removing J32) and am able to use the Segger J-Link. I'm now using our target board and still using the Segger.
Thanks for the reply. I've just give it another go with V1.0 firmware as this was also the one originally listed on the Segger site. Sadly no change. The windows driver works I think, because I can plug in a FRDM-K66 F board and it enumerates correctly - I see a CDC UART in device manager when it connects. I shall try it again with the PE one you link to.
My TWR-K65F180M always connects as a MSD and shows 'BOOTLOADER' but seems stuck in MSD mode. No problem with Zombie processes though.
Paul, on my TWR-K65F180M board, as long as the USB lead for OpenSDA is plugged into J7 the Orange/Red Reset LED is on regardless of the position of the jumper on J6 or the whether the reset button SW1 is pushed or not.
And I see a waveform on pin 21 of U2 the K20 serial interface MCU (or pin 1 of J6, same thing but more accessible) which looks like it's being pulled low and released every 150uS, it varies between 0.25v and about 1.7v. Is this correct? It doesn't look right. If it is correct maybe it's part of how the K20 polls its pin 21.
If this is wrong it might explain why I get nothing but MSD mode.
Yes, I only get the BOOTLOADER MSD if I hold the reset button down while
plugging in the USB cable to my PC. In this BOOTLOADER state, D3 is
blinking orange. I don't see any activity on J6-pin 1.
If I plug in the USB without holding the reset button down, I don't see the
BOOTLOADER drive but I do get a COM port. Again, no activity on J6-pin1.
Is there a way you can try a different board?
On Thu, May 26, 2016 at 6:07 PM, petec20 <email@example.com>
Just to finish off here. I did find that the K20 was corrupt, as reflashing it through its JTAG port on J5 with firmware now uploaded to the thread here TWR-K65F180M board unintentionally secured has cleared the problem and the TWR-K65F180M now works in both MSD & COM port modes. Thankyou for your help Paul in establishing that. Now I can try to fix the original problem!
Thankyou for a clear and unamibuous description of the bootloader workings, just what I needed. From that description, and especially the bit about not having activity on J6-pin1 I initially thought that I had a corrupt K20. I got my FRDM-K66F board back today and it does have a K20 based OpenSDA interface on it. When I plugged it in, to my surprise it DID initially have activity on J6-pin1 and I saw a low duty cycle rectangular pulsed waveform with a period of about 150uS again, yet it also appeared as CDC device. Cycling the power since and this activity has not returned, J6pin1 is quiet in both modes now. BOOTLOADER and COMs mode can be selected correctly. OpenSDA on this board works and that in its self is a big help to see a working board. I've never used OpenSDA before, choosing to avoid it as final boards will not use it. I like to debug with hardware as close to the final setup as possible.
Paul many thanks for your post as it's helped push this on. Though its not solved yet, I now have a working & non-working version to look at.
If you have the new TWR-K65F180M Rev D board chances are you have the MBED firmware loaded by default.
Press reset button, plug in the USB cable to enter BOOTLOADER mode.
Drag-n-Drop the attached ZIPed *.binary file onto the BOOTLOADER driver. Ignore the naming convention. It really does work :-)
Un-plug and re-plug USB cable and you should have the OpenSDA debugger interface available.
I have problems getting the OpenSDA debugger interface to work with my TWR-K65F180M revision D board through Kinetis Design Studio version 3.0 running in Linux. The board came with the MBED firmware loaded and I've transferred the binary from David's post (which I believe comes from P&E's 2016-02-08 firmware apps release) to the board in bootloader mode. Now the board enumerates as follows
Bus 002 Device 021: ID 1357:0089 P&E Microcomputer Systems
At this point I should be able to debug a project through KDS using an OpenOCD debug configuration, if I understand it right. However, when I launch my configuration, KDS reports
"An internal error occurred during: "Launching New_configuration".
Has anyone seen the same error?
It turns out that a software update of KDS caused the error in my previous post. Following the steps in the thread https://community.nxp.com/thread/363937#545470 changed the situation. Now, KDS reports another error on launch =>
Open On-Chip Debugger 0.8.0-dev (2015-01-09-16:23)
Licensed under GNU GPL v2
For bug reports, read
Info : only one transport option; autoselect 'cmsis-dap'
Error: unable to open CMSIS-DAP device
Error: unable to init CMSIS-DAP driver
Error: Error selecting 'cmsis-dap' as transport
Runtime Error: /opt/Freescale/KDS_3.0.0/eclipse/../openocd/bin/..//scripts/kinetis.cfg:3:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'interface' called at file "/opt/Freescale/KDS_3.0.0/eclipse/../openocd/bin/..//scripts/kinetis.cfg", line 3
I suppose this means that the OpenOCD plugin in KDS depends on an particular formware (CMSIS-DAP) on the board. Is OpenOCD in KDS simply incompatible with the P&E bootloader firmware posted earlier in this thread?
I am doing TWR-K65F180M Rev.D testing.
I did update *.BIN file and can see OpenSDA CDC port and can display X, Y tilt data on Hyper Terminal now.
But, when I start launching OpenOCD and get error "OpenOCD failed with code(1).
Could you help me to fix this problem?
thanks for your answer.
but after copying the bin file to the bootload mass storage device, the onboard led starts to flash fast and after a power cycle, no usb device gets enumerated.
I tryed it a few times more and now the OpenSDA gets enumerated. Thanks for the binary!
What is the revision of your board labeled on back side?
Can you take image of contents of BOOTLOADER folder?
Sent from my iPhone
I wanted to add that I just went through this procedure but the debug session still failed. The final problem was due to 'zombie' processes still left over from my initial debug attempt - this is described quite well in Erich Styger's tutorial in
(see the Troubleshooting area).
As a suggestion, the driver David provided in the earlier port here:
should be more widely available than just as a response in these forums.
In case it's still useful, the board is labelled as 700-28036 Rev A and SCH-28036 Rev D. I just purchased it from Mouser last week.
The BOOTLOADER image shows up as:
did you manage to debug your board with the CMSIS DAP firmware finally?
or was it just working with the P&E firmware ?
I can work with the P&E firmware to use the K20-based debugger, or I can use the Segger firmware to use a J-Link Plus debugger (which is what I will be using on the final target board). I was not able to get the OpenSDAv2 debug interface working.
this is sad.
I was hoping to have a debug probe to test ARM DS-5 with...