After receiving my JTAG connector, LiPo battery, and Olimex ARM-USB-OCD, I could finally set to work getting the Mikeycard to do something!
The first task was to ensure we could communicate with the processor using the JTAG interface and then flash a .bin file to the internal flash memory. This should have been a fairly easy task – there are quite a number of OpenOCD config files kicking around for the AT91SAM7S series of processors.
Everytime I tried to flash (and then verify) an arbitrary .bin file, I was getting failures or errors. It was at this point that I noticed that some of the lockbits were set on the flash (this can be seen with the “flash info 0″ command in OpenOCD). So I tried clearing these bits with “flash protect 0 0 15 off”. However, OpenOCD was again showing errors.

Not working...
At this point I stripped the OpenOCD config file back to the bare minimum, leaving the processor to run from it’s internal 32kHz clock. This time I could clear the lockbits, and flash the memory successfully.
So, it looks like the clock isn’t running correctly using the default values in the OpenOCD config files. What do all these registers actually do? Let’s look at the appropriate part of the file:
mww 0xfffffc20 0x00000601 # CKGR_MOR : enable the main oscillator(18.432MHz)
mww 0xfffffc2c 0x00481c0e # CKGR_PLLR: 96.1097 MHz(18.432MHz/14*(72+1))
mww 0xfffffc30 0x00000007 # PMC_MCKR : MCK = PLL / 2 = 48 MHz
The first memory write to 0xFFFFFC20 – what do those bits mean? The first bit tells the processor to enable the external oscillator. Bits 8-15 represent OSCOUNT – the delay until the oscillator has stabilised. I popped the oscilloscope onto the external oscillator, and when this command was issued, the oscillator successfully started up. It did take longer than I would expect, so we may need to increase the 6 to something larger later, or tune the load capacitors slightly.

Showing the length of time taken for the oscillator to stabilise
Even with the external oscillator running, the processor is still using the internal clock, so at this stage I was still able to flash successfully.
What about the next command that writes to 0xFFFFFC2C? This is to set up the internal PLL which can be used to adjust the clockspeed as required. The 0x00481C0E value seems common, but again, what do the bits mean?
0-7 is the PLL DIV
8-13 is the PLL COUNT (how long to wait for it to stabilise, similar to OSCOUNT above)
14-15 is the PLL output frequency range
16-26 is the PLL MULT
So – the common value of 0x00481C0E means divide by 14, wait for 28, output freq range is 0 (80-160Mhz), and the multiplier is 72. This gives an output frequency of 96.1097 MHz.
The next command – this changes the oscillator source from the internal one to the PLL, and sets the PLL prescaler (another divider) to 2. This means that the processor should now be clocked at about 48MHz.
However, at this stage I can no longer write to the flash.
What happens if I set the prescaler to 4, giving a clock speed of 24MHz? It’s now working. Maybe the processor won’t run at higher speeds?
I then tried it using a different multiplier/divider ratio (96/6), which with a prescaler value of 4 should give us approximately 50Mhz. Surprisingly, I could still flash the memory.
What’s going on here? I’m not sure. My suspicion is that the values of the capacitors and resistors in the external PLL filter aren’t quite right, and for whatever reason the usual PLL settings just won’t lock correctly.
Cybergibbons