RFID freak

The next stage was to flash the memory with something a bit more useful that an arbitrary bin file!

For this, we need a toolchain. I’m currently working on a Windows PC, and the Olimex ARM-USB-OCD came with a CD – ARM GCC for Windows Dummies. This installs the Yagarto toolchain, along with Eclipse, Zylin and OpenOCD. It (mostly) worked out of the box, though I did need to explictly define several paths as there are about 4 versions of “make” on this PC.

There is a good tutorial and set of examples here (warning, large zip) that help you get a Windows toolchain set up.

I then decided to take one the simple flashing examples, cut it right back to the bare minimum, and flash the LEDs on the Mikeycard. I changed the PLL setup in LowLevelInit.c as per the earlier post, and just toggled the IO pins inside a while loop. After a couple of tries and sorting out basic mistakes, the Mikeycard was alive!

The code I have used can be downloaded mikey-at91sam7s512 and the resulting main.bin as well.

I believe Roel has managed to compile the same code under Ubuntu.

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

Just a quick note to say that CyberGibbons has coded a program that makes all LEDs blink!
More to follow soon….

Just added a Google code project.

Here: http://code.google.com/p/mikeycard/

Watch the first video of Mikey in action!

HERE: http://www.youtube.com/watch?v=qjZKkpdFBdQ

Here’s the log of that OpenOCD session:

root@tom-T43:/home/tom# cd Desktop/
root@tom-T43:/home/tom/Desktop# openocd -f arm7_wiggle.cfg
Open On-Chip Debugger 1.0 (2008-11-26-09:42) svn:unknown

BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS

$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
jtag_speed: 1
Info: JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
Warning:no tcl port specified, using default port 6666
Info: accepting ‘telnet’ connection from 0
target state: running
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xb00000d3 pc: 0×00048580
target state: running
Info: JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
Info: JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xb00000d3 pc: 0x0003c5a8
Info: JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xb00000d3 pc: 0x0003c5d4

And this is from the telnet session:

tom@tom-T43:~$ telnet 127.0.0.1 4444
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
Open On-Chip Debugger
> poll
target state: running
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xb00000d3 pc: 0×00048580
> resume
> poll
target state: running
> reset
JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
> reset
JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xb00000d3 pc: 0x0003c5a8
> reset
JTAG device found: 0x3f0f0f0f (Manufacturer: 0×787, Part: 0xf0f0, Version: 0×3)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xb00000d3 pc: 0x0003c5d4

I can go to sleep happy.

What I’ve noticed so far is that with an unprogrammed Mikey you have to attach a working battery and then it starts with all lights on. You can do JTAG and everything you want.

All lights go off as soon as you remove the battery and keep only the USB attached. The voltage on the breadboard area between 3V3D and GND will then drop to 1.8v. BUT the processor keeps running! So what’s all that about? No clue yet. I’ll keep on testing.

Cheers,

Tom

Hey all,

Today I could, finally, spend some time on debugging. And basically after soldering the battery header and attaching my old iPhone 2G battery all the lights came on, and they stayed on!

I attached the USb and everything was fine.

Plugged in the JTAG and it was still OK.

Started up OpenOCD and I the funky device ID was gone!

Telneted to the OpenOCD server and I could halt the processor!

WHAT A JOY!

I am one very very happy camper.

Now my battery is dead again, and now Mikey showes the same behaviour as before.

It looks as if an unprogrammed Mikey won’t start without a battery. My guess is because a virgin ARM will trow all ports high and hence put the LTC 4088 battery loader in suspend mode, which in his case shuts the ARM down. Anyway I’m not sure about what exactly is going on around there but I am pretty sure that it is the interaction between the CPU and the battery charger is the cause of the processor not getting power.

Oooh yeah, did I mention that was on a board with R6 removed?

Well problem solved, for now. On to the next challenge.

Cheers,

Tom

EDIT1:

I have to thank d18c7db for all his help and for suggesting the solution. Thanks dude!

So I’m not an electronic engineer and I’m still trying to build this thing. Crazy I know.

It looks like  the Device ID that I get from the ARM is consistent with the case described in page 51 and further of the datasheet. As stated there and also on page 14 of the same document. When JTAGSEL (pin50) is high it jumps into JTAG boundary scan mode. A quote from page 14 :

The JTAGSEL pin is used to select the JTAG boundary scan when asserted at a high level. The JTAGSEL pin integrates a permanent pull-down resistor of about 15 kΩ to GND, so that it can be left unconnected for normal operations.

Page 51:

EmbeddedICE mode is selected when JTAGSEL is low. It is not possible to switch directly between ICE and JTAG operations. A chip reset must be performed after JTAGSEL is changed.

On Page 52 we read:

IEEE 1149.1 JTAG Boundary Scan is enabled when JTAGSEL is high. The SAMPLE, EXTEST and BYPASS functions are implemented. In ICE debug mode, the ARM processor responds with a non-JTAG chip ID that identifies the processor to the ICE system. This is not IEEE 1149.1 JTAG-compliant.

And at the bottom of page 56 we find our funky Device ID.

AT91SAM7S64 | 05B0_603F
AT91SAM7S128 | 05B0_A03F
AT91SAM7S256 | 05B0_903F
AT91SAM7S512  |05B1_A03F

Conclusion:
It seams like JTAGSEL is HIGH and the proc is running in JTAG Boundary Scan mode.
Good that this is clear.

Now what?

Looking at the schema and the PCB I can see that JTAGSEL (pin50) is connected to E18 and to R6. On page 1 of the schema (Top.SchDoc) in the lower left corner (at coordinates C2) you’ll find E18. The culprit for keeping JTAGSEL high you’ll find on page 2 of the schema, in the lower right hand corner (at coordinates C6). There you see that R6 is connected JTAG SEL and to 3V3D.

So I presume it must be R6 that’s keeping JTAGSEL high and that removing R6 will make it low again.

Then yesterday evening, in the few minutes that I had to work on the board, I did the following:

• Power up the board and as usual all the lights came on and JTAG responded with the same ID.
• Then removed the power and stripped R6 cleanly from the board.
• Powered up the board again and NOTHING HAPPEND! No lights, no response on the JTAG nothing! And on the breadboard area, where before I could measure a clean 3.3volts, I now measured only 1.8volts!

What’s that all about?

I figured that I must have overheated something or blown some solder away buy putting the hot air to strong or whatever. So then I took the other board. Checked if that was acting normal -and it was- and nicely removed R6 also from that one. Powered it up and same thing. Nothing! Dead bird, no fly. Finally I placed R6 back and Voila! all back to the normal boundary scan mode.  So what does R6 do? How come it influences the board so much?

That’s got me puzzled….

I’m stuck.

Any and all ideas more then welcome.

Cheers,

Tom

Hi,

While I was sleeping Matt responded with how I can find / calculate the values for the C’s and R’s near the antenna area. This is what he said:

Tom,

Regarding your second question. The basic idea is you need to resonate the series combination of C36 and C38 with the inductance of your antenna to 13.56 MHz.

C = C36 C38
L = inductance of your antenna

frequency = 1/(2*pi * sqrt(L*C))

You may have to tune the parts to take into account for board strays.

Also, initally make R17 and R18 0 ohm. You may increase the values of these parts if you need to widen the bandwidth of your tuned circuit.

Make C34 and C39 0.01uF

Good luck,

Matt

So now I have to find the inductance for these antennas and I’m done! I mailed them just a few minutes ago and they told me the antenna does not have a datasheet but they did send me the whole schema and PCB layout.  So now what !

To much to do.