Since the last post I spent quite some time with my new tool to dump sequences from my commercial debugger. After comparing these dumps to various codebases I found online (libswd, cmsis-dap, mchck) and comparing them to the various manuals on the subject, I managed to extract the command sets for a set of essential functions:
1) Peek/Poke (universal to all ARM cores)
2) Halt/Continue (universal to all ARM cores)
3) Reset (Freescale specific)
4) Mass erase (Freescale specific)
With these command sets figured out, I was able to recreate them on a standard Arduino and trigger them with a simple serial remote control application. I also managed to figure out how, when and why all the various types of registers are available to read/write over the debug lines. In the case of the Freescale chips I’m targeting, some features are only available after setting certain bits somewhere else. Others only work when the system resetpin is activated. Joy.
Example: reading the identification register to see if the chip has powered up correctly. The magic value here is the 0x04770031 at the end.
Figuring all this out has brought me much further along the path – I am now almost ready to start executing flash commands on the target device. When the system can flash the MKL26 and MKL02 chips I am planning to move the codebase from the Arduino it lives on now to a set of dedicated small/cheap boards. One of these will be another USB-stick type PCB (plugs straight in to a USB port) with a simple row of programming pins meant to program microgameboys – possibly pogopin holder.
One of the great breakthroughs of the Arduino has been that to get started, you only need the device itself and the software. The try/fail/try again cycle of development got reduced to altering your code and pressing run (again).
Most other platforms completely fail in this respect. Many chip-manufacturers have excellent and cheap try-out boards that are even pin compatible with the Arduino. However, while Arduino gets many things right – hardware choices and software choices are not two of them. The Atmel AVR series is easy but outdated. The Arduino “IDE” barely beats notepad.exe in functionality and project management.
Chip manufacturers almost invariably fail to recognize that having to struggle through ANYTHING between the compile button and the thing actually running your code is losing them enthusiasm, mindshare and ultimately customers. Because the manufacturers have no idea how to approach this part of the developer experience themselves, and apparently no inclination to get involved, they attempt to extend the Eclipse IDE (with endless pages of settings tabs) or try to become hardware compatible with Arduino.
So when I was recently asked if I would like to host a workshop programming games for the latest incarnation of the microgameboy, I had a problem! There is no real foolproof way to even talk to these chips! The official toolchain only supports a handful of programmer devices you have to attach separately using a tiny halfpitch connector that is not easy to find. This will not do for novices.
So part of my “this really should NOT be Rocket Science” quest has become this:
Make developing for a platform like the microgameboy EASY.
Stage one: creating a cheap tool to connect the microgameboy to your pc to update the program memory.
The chip I am using in the microgameboy is made by Freescale (the MKL02Z32 to be precise). This chip belongs to the ARM Cortex M0 family of devices. ARM is a big company that creates standard designs for chips. If you keep to the standard, software written for that standard will run on your device. Luckily, the Cortex standard includes a chapter on the debugging interface. The debugging interface allows anyone to inspect the inner state of the chip and poke around in its system memory. With some clever mangling (and the manual from Freescale – since this bit is outside the Cortex standard) you can trick the chip into updating/rewriting its own flash memory. This is what I’m going to do.
The first step of such an undertaking is (as usual): Homework.
KL26 manual by Freescale
There are endless stacks of documents to be found that all refer to the debug interface in some way or other.. which always leads me to:
The second step of such an undertaking is (as usual): screw this shit..
I am not going to sit here reading 5000 pages of dense text. I’ll have a look at the actual data instead.
Last year I ordered a whole bunch of tools to deal with inspection of electrical signals. Amongst this set is an Open Workbench Logic Analyzer by GadgetFactory. It allows you to record a whole bunch of signals at the same time, at very high speeds. Using this device, I got this:
Saving this to a file and parsing the file for clock/data state transitions got me this huge array of bits:
data dump from jlink capture:
As you can see, the file contains some obvious patterns, creating diagonal lines in the data dump like 60’s wallpaper. By pressing enter at the diagonals, I separated the data dump into a more logical grouping of bits.
Almost repetitive, I did not manage to create a straight line but again revealed a pattern in the data. I remembered reading about the packet layout somewhere on the first pages of the manuals. The packets should be 8bit – pause – 3bit – optional pause – 33 bit – optional pause. Let’s see how that fits the data:
Way better again. Especially the centre column of 100s is looking good! This is the ACK-message of the SWD-standard.
To parse it I had to look at the manual again *sigh*. There are some bits in the protocol that allow the chip to do sanity-checking on the signal. Start bit, stop bit, park bit, parity bit – checking for these bits allowed me to sync the signal even better. More manual readings gave me the names of the various registers and bits. Read bit, write bit, debug bit, ACK, error and all that jazz.
Behold the interpreted bit stream of a commercial programming box talking to a Freescale-chip:
needle (0x0BC11477) in LSB first format: 11101110001010001000001111010000
AP R ?????? skipped: 11111111111111111111111111111
DP R ID DP R ID 0x0000001E 10000001 100 01111000000000000000000000000000 0
DP W CTRLSTAT -> 0x50000000 10010101 100 00000000000000000000000000001010 1
DP R CTRLSTAT 0x000000F0 10001101 100 00001111000000000000000000000000 0
AP R DATAREAD AP R ?????? DP R RDBUFF 0x00000000 10001101 100 00000000000000000000000000000000 0
AP W CSW -> 0x23000012 11000101 100 01001000000000000000000011000100 0
AP W TARGET -> 0xF0002000 11010001 100 00000000000001000000000000001111 1
AP R DATAREAD AP R TARGET 0xF0000FF0 11010001 100 00001111111100000000000000001111 1
AP R DATAREAD AP R DATAREAD AP R DATAREAD AP R DATAREAD AP R TARGET
Now that I had captured a real bit of setup-code that actually performed the thing I needed to do on the chip, I could rewrite it! With some tweaking, head-banging and by using the logic analyser again to check if my own output matched the official output – I managed to get something working. Now I have a way to dump the contents of the memory of any Cortex M0 device with an enabled SWD subsystem: