This post originated from an RSS feed registered with Python Buzz by Phillip Pearson. Original Post: Working toward being able to flash Kinetis E chips with OpenOCD, using USBDM flash routines Feed Title: Second p0st Feed URL: http://www.myelin.co.nz/post/rss.xml Feed Description: Tech notes and web hackery from the guy that brought you bzero, Python Community Server, the Blogging Ecosystem and the Internet Topic Exchange Latest Python Buzz Posts Latest Python Buzz Posts by Phillip Pearson Latest Posts From Second p0st

My J-Link broke yesterday, so I'm back to using either my FRDM-KE04Z board with USBDM firmware or my LPC-Link2 with CMSIS-DAP firmware to program my Kinetis E devices. USBDM seems to only support Windows and Linux, so I'm trying out the LPC-Link2 with OpenOCD today.

My chip is a Kinetis MKE02Z64VLD2 (64 kB flash, 4 kB RAM, 20 MHz max), which OpenOCD doesn't have a flash algorithm for. With any luck it should be able to debug my chip out of the box, but I'm going to have to steal code from USBDM to get it to download my code.

First things first... Homebrew seems to install OpenOCD 0.8.0 when you run 'brew install open-ocd', so I built and installed 0.10.0-dev from git. Copying /usr/local/share/openocd/script/kl25.cfg as ke02.cfg and running openocd with the following in openocd.cfg seems to get it started:

interface cmsis-dap
adapter_khz 500
transport select swd

source ke02.cfg

Once OpenOCD is running, it listens on ports 3333 (GDB remote protocol) and 4444 (command shell). telnet localhost 4444 gives you something like the J-Link Commander console. 'reset' and 'halt' do the expected things, so it looks like it's handling the SWD protocol just fine.

Now to figure out how to extract the KE02Z64 flashing code from USBDM... here's what I've figured out:

• USBDM flashes the KE02 using its Kinetis-FTMRH-flash-program-gcc helper, which is downloaded into the target over SWD, then executed to copy chunks of code from RAM to flash.
• The metadata mapping devices to flash routines is in arm_devices.xml.
• It looks like flashing happens via the FlashProgrammer_ARM class: loadLargeTargetProgram loads the flash helper into the target's RAM, and executeTargetProgram runs it.
• It looks like the target program contains a header, at a known location in its data segment.

So it looks like we have all the pieces of the puzzle... the trick will be to get FlashProgrammer_ARM.cpp wired up to OpenOCD's interface code, so it can write and execute code on the target.

(to be continued)

Comment