I believe I may have found a two part solution for my particular problem. I currently own an Arduino Diecimila (which has the ATMEGA168 with the problem) and also a new Arduino Nano 3.0. I went ahead and flashed the Arduino Nano with the ArduinoISP firmware. I then picked up 3 28 Pin ATMEGA328P DIP chips for $5.00 each at the local electronics store.
I used the ArduinoISP to flash one of the virgin chips with the Arduino Firmware using the above link with a crystal. I plan to now flash one of the other ATMEGA328Ps with the High Voltage Programmer firmware. This chip along with a bit of wiring on a breadboard should allow me to reset all of the fuses on the original ATMEGA168. Once that is done, I will be able to use the Arduino Nano to reprogram the chip.
Since the ATMEGA328Ps only cost $5 each, my end goal is to setup one 328 as an Arduino ISP programmer, setup the 168 as a HV Programmer, keep one 328 chip in my current Arduino Diecimila (upgrade!!), and I'll have one left over for whatever. I can then either switch chips on the Diecimila or build out a real board for the ISP and HV Programmer boards.
I still have not tested the JTAG ICE MKII yet with a logic/oscilloscope. Not sure if it is the root of the problem or not. I will address this issue after I build the HV Programmer.
I will report back on the success/failure of the HV Programmer. I just need to go get a few more 1K resistors to pull it off. Anyone ever tried the HV Programmer? Any other suggestions? If nothing else, hope this helps someone.
I suspect the problem is not with your C code but with your Makefile.
The following lines in your Makefile produce an example.o object file.
main:
avr-gcc -g -Os -Wall -mmcu=atmega328 -c ../src/example.c
The created .o file only contains the symbols and code from example.c, not the additional source required to actually make it run on a target system such as interrupt vector jump tables and code to initialise the BSS RAM segment to zeros, and load your initialised data sections.
You'll need to add an additional line something like this to run the linker and produce an output object suitable for download to the AVR part. Alternatively, use avr-ld, but you'll have to work out all the required linker options.
main.elf: example.o
avr-gcc example.o -o main.elf
You can use avr-objdump --disassemble-all <filename> on both example.o and main.elf yourself to verify the different content of each file.
It's always a good idea to try to reduce your problem in steps to the most simple example possible. In this case, it would probably mean dropping into the AVR Studio software and creating a project running on the simulator using their managed build process. From there, you could them export the Makefile in use by their build process by using the 'Export Makefile' menu option. The generated makefile could then be compared with your version.
Actually, it's probably a good idea to use a Makefile similar to the one generated by AVR Studio because it has the correct rules already defined, you just have to set up some variables with regard to which objects need to be generated and the final target file name.
Best Answer
ARM microcontroller development is a little more complex. But, only really because DIP packages are generally not available.
If you're willing to use a development board, ARM development can be even easier.
The mbed is an ARM microcontroller on a breadboardable DIP shaped board.
The C/C++ compiler is web based and the board appears as a USB mass storage device. You download code by saving from your browser to the mbed. Even easier than a basic AVR setup.
Once you outgrow this setup, you can run gcc locally on your PC and still upload via USB. After that, you can move to JTAG using OpenOCD.