Raspberry Alpha Omega

Raspberry Pi from start to finish

ARM Cortex-M board from scratch part 3: Kinetis KE04

Jul 7, 2015 - 4 minute read -

If you have read my previous post in this series, you'll know that I had mixed feelings about the LPC810 and LPC812 chips from NXP. They are certainly simple and flexible in use, but without a stable and predictable technique to program them I just ended up more frustrated. However, I impressed myself by successfully soldering the surface-mount TSSOP package of the LPC812.

So this time I am attempting to scratch-build a circuit based on a Cortex-M0+ from completely different manufacturer, the Freescale Kinetis KE04. Unlike the NXP parts, this chip has no built-in bootloader, but relies on the "industry-standard" SWD protocol for programming and debugging. Freescale have a huge range of Cortex-M microcontrollers, but the reason I chose this particular one is that it comes in a similar package to the LPC812. I know I can solder this, and I already have a breadboard adapter to fit it.

I am quite familiar with the Kinetis range, having written software to run on their FRDM development boards, but have, so far, never worked with the bare chips. I already have the Freescale FRDM board for this chip, so I reckoned that I might be able to try out some software and the programming connections and protocols on a definitely working board, then try the same approach on my home-built one.

FRDM boards come with a separate MCU on the board just for debugging over USB. As delivered, this emulates a mass storage device. Programming is done by building a binary file, then dragging it onto the device using the host PC's file management tools. I can see why they do this, as it is pretty much independent of particular development tools. However, I want to build my software in Freescale KDE or Keil uVision and deploy it to the hardware using a generic debug probe.

I started by trying to connect my ULink2 debug probe to the FRDM board, but found a few problems. The first problem was that this device is only really supported by Keil uVision, so I could not easily use any of the software developed using KDE or Freescale CodeWarrior. The second, and more serious problem is that when I opened up my ULink2 to attach the Cortex-M SWD cable, the circuit board did not look much like the pictures on the Keil web site, and there was not even a header to fit the cable. Even though this device has worked well with several STM32 development boards using the 20-pin JTAG connector, I have now come to the tentative conclusion that the one I have my be either a "clone", or a reduced model which does not support SWD.

It took me a while to decide that the debug probe might be part of the problem. At the same time I was also poring over datasheets and reference manuals for the KEO4 chip. This was useful, as it suggested that programming would be both easier and more reliable with a 10KOhm pull-up on the RESET and NMI pins and a decoupling capacitor across the power pins. While experimenting, I used an oscilloscope to look at the signals on the pins and saw a strange repeating pattern on the RESET pin, even when pulled up. This puzzled me until I found a page on the Freescale web site and a stack exchange thread which explained that this is very common on new chips, and that any good debug probe should be able to halt the chip and clear the flash memory to stop this behaviour.

Without a working ULink2, one fallback position was to buy a real debug probe. However, a potentially simpler (and cheaper!) alternative would be to update the firmware on the FRDM board to act like the de-facto standard Segger debug probe. Erich Styger at MCU on Eclipse wrote a useful post on how to do this. It seems Segger provides official 'OpenSDA' software for this task, and installing it was pretty straightforward. I was soon able to download, run and debug software using both KDE and Keil uVision on the FRDM board. The next step was to connect the re-flashed debug probe to my scratch-built board. To my amazement, it worked, and I was soon running a 'blink' program.

I was so delighted, that I danced around my workbench a little, then tried again a few times just to make sure things were really working.

There is one fly in the ointment, though, the issue of licence terms and conditions. The licence for the Segger firmware for the FRDM boards makes it very clear that it is not to be used with external or custom boards, but only with the chips in situ on the FRDM development boards. So, strictly, by even trying this I was breaking the terms, and this is not an ethical or sustainable way to continue.

Next time I shall look at some other, more legal, ways of using Segger firmware.

Posted by Frank Carver adapter ARM Cortex Debugger freescale Freescale hardware IDE J-Link KDE KE04 Segger SMD SOIC soldering swd ULink

< ARM Cortex-M board from scratch part 2: LPC810 Freescale Kinetis KwikStik (part 1) >

Comments

  1. Erich Styger

    A legal way to use the FRDM board to program another board is to use USBDM or CMSIS-DAP instead. I know that many are using USBDM, but for me I had no luck with it under Eclipse. But that might be an option for you. What worked well for me is using the CMSIS-DAP firmware instead of the Segger and P&E one. See http://mcuoneclipse.com/2013/05/17/cmsis-dap-with-iar-and-the-kl25z-freedom-board/ I hope this helps, Erich

  2. Frank

    Thanks Erich. Those two are next on the list after I write up my further experiences with Segger.

  3. Ken

    Hi Frank, Interested in some of your Forth-like stuff from a couple of years back. We appear to be following similar journeys. I started to write a simple language tool called SIMPL (serial interpreted microcontroller programming language) , to allow new hardware designs to be exercised, provided you have a working UART. It's a bit Forth-like - but actually has an interpreter written in C. I have run it successfully on AVR, M3, M4 and M7 ARMs, and also a soft core processor called ZPUino - which runs on a Xilinx Spartan 6 FPGA, and outputs VGA. I have now got the FPGA bug - and have been looking at James Bowman's excellent J1 Forth processor http://www.excamera.com/files/j1.pdf I hope to port my SIMPL language across to this - so as to use it to exercise FPGA hardware. I have a half baked plan to use SIMPL as a reduced Forth that allows me to write code for the J1 - very much a work in it's infancy. regards Ken

  4. Frank

    Thanks for getting in touch, that all sounds very interesting, particularly the FPGA Forth processor - I have found regular multi-register CPU designs sometimes an odd fit for a stack-based language. I must write a bit more about the progress I have made since this little blog series.

Leave a Reply

Your email address will not be published.