Update on setting up a development environment 2006-10-17

Well it's been a while nice I've added a new entry but I have been busy doing a lot of work on this project.

I've been doing a fair bit of research and reading on the ARM architecture and ARM assembly, and on the gnu tools (ld, gas, gcc). This is some of the documentation that I found useful:

ARM v5TE Architecture Reference Manual
ARM7TDMI r4p1 Technical Reference Manual
GNU ARM Assembly Quick Reference Guide
binutils documentation
gcc documentation
ADuC70xx Series: Precision Analog Microcontroller 12-bit Analog I/O, ARM7TDMI MCU Data Sheet (Rev. B, 4/2007)
ADuC7019/ADuC702x: Silicon Anomaly List (Rev. D, 8/2007)
ADuC7019/ADuC702x: Silicon Anomaly List (Rev. C, 4/2006)
ADuC7019/ADuC702x: Silicon Anomaly List (Rev. B, 3/2006)
ADuC702x Serial Download Protocol

So with some reading and a bit of reserarch I was been able to come up with a Makefile, linker script and some boot code. This produced a memory image in Intel HEX format that just needed to be uploaded over the serial cable.

I tried using lpc21isp but it just would not work for me. I tried the beta versions avaiable from the the members section of the Yahoo Groups but no luck. I even tried debugging the code but I couldn't find the source of the problem.

So the solution was that I wrote a new Linux serial download program for the ADuC702x in C.

Now that I was able to upload firmware I could get around to testing by boot code. The basic steps of the boot code are, the hardware triggers a reset exception, the exception is handled by some assembly which sets up a stack, calls the main function in C, the C code sets up the serial port and writes "Hello World!\n".

But it didn't work, I could print individual characters and turn on and off the led, but when I called my write_string function execution would just stop. After looking at the assembly dumps and quadruple checking all the code I couldn't see what was causing the problems.

At this point I've spent two days looking at the code, reading documents and googling. I knew the problem was caused by some form of data alignment problem, ARM processors required 4 byte read/writes to be aligned to 4 byte addresses.

I then decided to look at the linker script again. This time I looked at the MEMORY command and converted the hex values to decimal and noticed that the length value for the sram was a odd number. I then realised that the top of the stack was calcuated as (base_memory_address + length - 4) which would give an unaligned address.

So changing the length of the sram from 0x1FFF (8191) to 0x2000 (8192) solved my problem, the best bug squashing stories have the simplest solutions.

The software isn't in a state to release yet, but I'll clean it up and make it available in a few days.