Talkback for article: 231, March2002

Programming the ARV Microcontroller with GCC

Back to:

From: Thomas <th.lehwald(at)> [ date: 2002-03-01 ]
Hi folks,

I think this article is a very important step in the right direction. It should give more of that kind. Linux is a good choice for a development platform and why not as a cross platform for micros?
The article itself has a clear structure and discribes all necessesaries to start with avr-gcc.


From: peter schmitt [ date: 2002-03-15 ]
very good article
From: Jan Svenungson <jan.svenungson(at)> [ date: 2002-03-22 ]
O man! This is so cool... Im new to this kind of hardware experimenting but it is so fun...
And there AVR stuff are cheap to... Im sure going to build this stuff and hack away...
From: Harinder <dhingra_h(at)> [ date: 2002-03-28 ]
Good, to start the things. Teachers and students can be beniffited with this.
Can a article on PEC from Microchips can also be given.

From: DS Oberoi <ds_oberoi(at)> [ date: 2002-03-29 ]

Anyhting on similar lines for 8051 family (INTEL) also.
From: Robos [ date: 2002-04-02 ]
Nice article. Nice to know that such a controller exists and that it is so simple to attach the controller to the host computer. BUT:
Why is the layout of the microcontroller given in some sort of ordered fashion and not as it is with the real thing? When you want to build the thing you have to compare the given schematics with the actual layout of the avr which is rather error-prone. And, more problematic:
The layout for the connecting cable is simply
The layout on the board is given as GND - 19 - 18 - 17 - Reset AND NOT as given in the cable part as 19 - 18 - 17 - Reset - GND (in the side-by-side part)!!!
Can somebody with some electronics knowledge tell me if this switch could fry anything? Southbridge? Or only the AVR?
From: guido socher [ date: 2002-04-02 ]
This is a reply to the previous talkback:
The schematics of circuits are by convention drawn such that
they are easy to read and understand. The symbols never reflect the
exact pin position of the real devices.
The cable is correct as far as I can see. It does not matter which wire is
left or right. Unless you use a flat band cable you will anyhow not have any
physical order. The only thing that matters is: Which pin from the parallel
port is connected to which pin on the AVR:

pin on AVR -> Pin on parallel port
SCK (19) -> Strobe (1)
MISO (18)-> Busy (11)
MOSI (17)-> D0 (2)
Reset (1) -> Init (16)
GND -> GND (18)

This article is nothing for people who have no experience with
electonic circuits.

From: Udo Puetz [ date: 2002-04-08 ]
/dev/parport0 is missing under debian woody. You can create it with
the command:
mknod /dev/parport0 c 99 0

From: Arno Wilhelm <a.wilhelm(at)> [ date: 2002-04-26 ]
Great article. It gives a very good start for people who want to dig deeper into microcontroller programming!


From: Anonymous User [ date: 2002-04-30 ]
I have been programming the AVR with assembly (avra-0.7, ponyprog)
for some time now. This article is the first comprehensive avr-gcc
howto under linux that I have seen. Good work! The code example and
the Makefile is very valuable.


-- Mike D
From: Greg Pratt <gpratt3151(at)> [ date: 2002-05-23 ]
I am very pleased to see such an article. I've been looking at ways to do some Analog to Digital Conversion for logging purposes whilst using Linux as the platform. Thanks for starting basic and building from there.
From: Leonard Penzer [ date: 2002-05-30 ]
Great article.
But I had to add /usr/local/atmel/bin a little bit further - before doing make for gcc-core. Perhaps it could be fixed in the article.
From: Craig Limber <ffdude(at)> [ date: 2002-05-30 ]
Hey there;

I have a question: what is the sequence for bringing the power on?
Do I power on the AVR before doing the load or after? I want to
embed my AVR into a little mobile robot. Basically, I guess I want
to know if I have to have a "program mode" switch on the robot to
keep it from wandering off and trying to drag my computer along
behind it when I try to update its programming. Can you program
the AVR when it is trying to run the previous program?
From: guido socher [ date: 2002-06-06 ]
Hi Craig!
The AVR needs to have power before
you program it. The programer software will set it into a mode where
all input/output lines are "just floating" (open collector).
Note also that the makefile is designed such that the programing is
done in 2 steps: First erase then program.

This means it will execute any old program and then suddenly stop when
the programer gives it a reset and goes to programing mode.

If the AVR chip is fresh from factory then it contains nothing. Everything
is zero in the EEPROM and the AVR will do nothing.

From: Michael [ date: 2002-06-10 ]
Great stuff.
I'd suggest showing how to get gdb going as a future article.

Now for my question.
How does the linker file work for this? I noticed one isn't used and it somehow grabs a premade one. Can you explain how to change that? I know people can. Also, is there a reason it would be required? I saw that a 'C' application on ATMELS web site had included a .xcl file along with the C code. In the header of their linker type of file it says:

XLINK command file for the ICCA90 C-compiler using the -v1, -ms options.Segments are defined for a generic AT90S with a maximum of 64 Kbytes data address space and 8 Kbytes program address space.
Usage: xlink your_file(s) -f lnk1s

From: ditto <ditto(at)> [ date: 2002-06-12 ]
i have build it, it's OK, i want to go on make a new circuit,

From: Greg Pratt <gpratt3151(at)> [ date: 2002-07-09 ]
Finally got all the parts from your article except I used a ATS902313.
Everything went smoothly and I have my flashing green LED! Fantastic
article. Keep up the great work.

From: Jonathan Richards [ date: 2002-07-15 ]
Its a great article, very concise and tells you just what you
need to get started.
As I didn't want to risk blowing up my motherboard parallel port
I bought a 2 port pci parallel card from RL Supplies, connection with them)
No problems getting it running from the Linux-friendly instructions
and uisp works if you then use /dev/parport1 or /dev/parport2.
From: Nicolas Scheer [ date: 2002-08-01 ]
I like the clear, precise and useful things.
It's so rare on the net.

From: iitze <iitze(at)> [ date: 2002-08-04 ]
I have a big trouble!! It can't work.
Could someone help me??

I don't have 4433, so I use 8515 to test.
I also make pins right,
pins on AT90S8515 <---> name <---> pins on parallel port
6 MOSI 2
7 MISO 11
8 SCK 1
9 RESET 16
40 VCC 40
20 GND 18~25

and I replace "MCU=at90s4433" to "MCU=at90s8515"
`make` will be ok.

Then when I key in `make load`,
it shows
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
An error has occurred during the AVR initialization.
* Target status:
Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff

Probably the wiring is incorrect or target might be `damaged'.
make: *** [load] Error 2
But if I add `-dpart=at90s8515` in that line
then it will ok, too.
I also add `-dpart=at90s8515` in next line
key in `make load`
it seems uploading hex file.

But but..
the LED does't light.

I have spent a lot time to find out what't wrong
but it still doesn't work.
I also try download the code in the FLASH, but it also have some problem.
It seems don't detect the AVR.

How could I do, could someone help me, please?

From: iitze [ date: 2002-08-04 ]
oo, maybe I broke the ic.

I find article in the "avr-gcc-list"

> It's a well-known problem that it can sometimes happen to destroy the
> ID bytes in serial programming. Atmel acknowledges this in appnote
> 910, page 5:
> ``Table 5 indicates that the Device Code will sometimes read as $FF.
> If this happens, the part Device Code has not been programmed into the
> device. This does not indicate an error, but the part has to be
> manually identified in the programmer.''

Can I have any method to `save` the ic,
or at least I won't broke next one?
From: D.S. Oberoi and Stumpf Michael [ date: 2002-08-16 ]
A note on math and avr:
To use the mathematical like functions sqrt, cos, ... etc
with ARV, you need to "#include <math.h>" and link against the
libm.a library file, found in ../avr/lib directory.
and by setting -lm option.

The floating point support for AVR-GCC is only for 32 bit float,
say double equals float and has the accordingly accuracy.

From: Akhmad Fathonih <akhmad_f(at)> [ date: 2002-09-06 ]
I'm new in this area and I found this article very attractive to read.
I've been facing the difficulties on electronic matter since I don't have any electronical background (I've been taking Computer Science).
So, I'll be very happy if there are articles to ppl like me.
From: Stan <Stanman17(at)> [ date: 2002-09-16 ]
I have a problem. I have a royonic and that machine need a floppy disk to boot from every time you put it on. I wand to make a print whit a Eprom and a microcontroller. And whit a Floppy disc conector. So the microcontroller must simulate a disc drive. Is that possible and how?

regards Stan
From: stalyc <starlyc(at)> [ date: 2002-09-24 ]
From: Floris <floris-(at)-linuxfocus-(dot)-org> [ date: 2002-09-27 ]
Hi Guido.
Is there any particular reason that you use an AVR instaed of an Atmel PIC?
I am familiar with the PIC 16F860 (or 16Fsomething else) but not with the AVR - they seam to be pretty similar.
Why did you choose AVR over PIC ?
From: guido [ date: 2002-09-28 ]
Hi Floris,
because I wanted to have a good C compiler and Linux
development environment for the uC. Apart from that
AVR has more advanced features than PIC.
From: Floris <floris-(at)-linuxfocus-(dot)-org> [ date: 2002-09-29 ]
Yes I understaind.
I once found some GPL Linux PIC development tools on the net, but there was no C compiler I believe.
I still have one PIC (blew up the other one!) and maybe some day I'll try to use it with Linux. I don't need C at the moment, but it really can be a huge advantage. The advantage of the PIC is (I think?) that it is still a bit cheaper than the AVR.
From: jk <jink(at)> [ date: 2002-11-05 ]
very good article,please go on
From: RoBSki! [ date: 2002-11-07 ] , my free AVR stuff :) ciao
From: zebaze kana M.G. <zebazem(at)> [ date: 2002-11-09 ]
It sounds cool, but the usual trend is to download the code using the Serial Port
From: Craig Limber <ffdude(at)> [ date: 2002-11-18 ]
Did anyone manage to make this work?

I could not. Tried two different computers/OS versions, and MANY
difference versions of uisp/avr-gcc/avr-libc and always I got this:

uisp -dlpt=/dev/parport0 --erase -dprog=dapa
An error has occurred during the AVR initialization.
* Target status:
Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff

Probably the wiring is incorrect or target might be `damaged'.
make: *** [load] Error 2

I tried different 4433 chips but no joy. Power is good, all connections
are verified. When powered the AVR's clock is running at 4 meg (measured
it with a frequency counter). A logic probe shows action over the
parallel port (all modules loaded) but never gets past that one error.
Tried the same circuit one of my buddies using my computer and software
and got exactly the same message.

Parallel port works (verified with my PIC burner).

One thing I don't understand. At the top-left of the schematic there
is this little bit with VCC/GND and JP1. What is that for?

Any help will be humungeously appreciated.

Current OS and stuff: redhat 7.3 on AMD 1800. Also tried redhat 7.2
on PII 300. Tried every version of gcc-core, avr-libc, uisp and binutils
that I could find on the net in either source code or RPMs. I'm
stumped. *sniff*

From: Craig Limber <ffdude(at)> [ date: 2002-11-18 ]
NO WAIT! It works! I had a bad reset pullup resistor. It would
never go low when uisp was trying to talk with it. DOH! DOUBLE DOH!


From: honschu [ date: 2002-11-21 ]
Great Article

It would be great to read more. So I could increase my knowledge leaded by a master ;)
From: honschu [ date: 2002-11-21 ]
I'll build the Project.
Is it possible to use the Atmega8 instead of useing AT90S4433 without any
changes in hard and software? So I can write bigger C Programs.

The Atmega8 is a little bit more expensive, but has:

Flash Vcc Eeprom SRAM
Atmega8 8 KB 4.5V 512B 1 KB+32 Registers
AT90S4433 4 KB 4.0V 256B 128B+32 Registers
From: guido [ date: 2002-11-22 ]
Hello Honschu,
yes, you can use a Atmega8. Of course the pinout of the AT90S4433
is different from Atmega. Check which pin is PD5 on Atmega.
You can use the same C-code (the simple test program from this
article, not in general). You can not use the same object code.

From: Marko [ date: 2002-12-04 ]
Finally good and working instructions how to program avr in linux.
Only thing I had to do was 'export /usr/local/atmel/bin:${PATH}' BEFORE compiling gcc-core.
From: Brooke <brookbot(at)> [ date: 2003-01-18 ]
Great article, finally got mine built and working :)

o I had to add ../atmel/bin to my path
o For some reason my parport was /dev/parport1 and not 0 (RedHat 7.2 + patches)
o I also had to add the include path to the makefile (-I/.../atmel/avr/include) for io.h
o I moved the "while (ms) { ms--; " loop outside of the other loops in the delay to get control over the LED blink rate.

This chip is really cool.

If anyone is interested, I can have some 2 sided PCBs (Printed Circuit Boards) manufactured for this project and others. Making your own PCB, or using a proto soldering board and wires (my method) takes a long time , is error prone, and difficult for beginners. Soldering fabricated PCBs is a lot easier IMHO.

If there is enough intrest I can get PCBs for about $10 a piece, but it has to be a bulk order. If you are interested, send me mail.

I can also make kits for beginners if people want.
From: Brooke <brookbot(at)> [ date: 2003-01-18 ]
BTW- total cost of the project (parts + PCB) was ~ $30 USD

Of course I already had a 5v power supply. Oh yeah, I was able to run the LED test circuit off of 2 1.5v watch batteries! I measured the batteries and had just under 3v total, but the AVR still worked just fine! Really cool.

From: Pradyumna Sampath <prady(at)> [ date: 2003-01-19 ]
This is a great article who are going to start programming with Microcontrollers.I hope to see a lot more artcles regarding this subject.

Great work again
From: guido [ date: 2003-02-04 ]
As already pointed out in some comments above there is a
minor error in the article. You need to add the
directory /usr/local/atmel/bin already to your path after
the installation of binutils. This is because the binutils
are needed for the installation of gcc.

In bash this is:
export PATH=/usr/local/atmel/bin:${PATH}


From: w.Motzkus <dk5eg-hof(at)> [ date: 2003-02-06 ]
Tnx for the great effort to give newbies a big lift into the sizzling world of AVR's.
While trying to install the GNU binutils, the first problem I encountered was a missing version of binutils on the listed ftp-sites.
2.12.2 : yes! (among many others)
2.11.2.: no!
I used binutils 2.12.1 instead. Is this critical? And eventually responsible for the problems I encountered during the rest of the installation?

From: guido [ date: 2003-02-07 ]
Hello Motzkus,
this is very strage I can see the binutils-2.11.2.tar.gz
even today at

Check again the above links. 2.11.2 is there!
I have never tried 2.12.2 so I can't tell you.

From: W.Motzkus [ date: 2003-02-07 ]
Yep! Thats alright!
Meanwhile I did find the correct version. The bz2-Version.
Still, in the final round, while installingthe AVR-C-Library the same error message pops up.
Like I said: I' m a newbie and did stick to every literal of your installation script.
Starting directory and installation directory: I used them to the best of my knowledge, but obviously this is not good enough!
I keep trying!
Tnx for the quick response!

Winfried Motzkus
From: AUBRY Jean-Marc [ date: 2003-02-20 ]
Tkank you for this very good article,now I can start to work with a microcontroleur and develop program on linux machine.My problem is following, I can load the programm into the µC 2 or 3 times, but after with the command make load I have a following message :

Cannot identify device because is looked.
Device similar to the ATmega103-old is found.
Page write disabled
FLASH write delay ...
EEPROM write delay ...
Uploading flash
#Device is locked.
Adress out of memory range.
make: *** [load] Erreur3

Why this error? I work with a AT90S8515 and the makefile is OK
From: guido [ date: 2003-02-21 ]
Hi Jean-Marc,
I have never seen this problem myself but I have a friend who
had a new carpet in his room. I told him to take off the shoes and
the problem disappeared. These uCs are cmos devices and ESD can
easily kill them or damage them.
From: Jean-Marc <aubry.jeanmarc(at)> [ date: 2003-02-23 ]
I don't know where is a problem, but I have found I idea to work with UISP and the AT90S8535.I have modify the Makefile :


load :
uisp -dlpt=/dev/parport0 --erase -dprog=dapa -v=3
uisp -dlpt=/dev/parport0 --upload if=avrledtest.hex -v*3 --hash=32

(to clear program into the memory µC)

erase :
uisp -dlpt=/dev/parport0 --erase -dprog=dapa -v=3

(to load program into the memory µC)

load :
uisp -dlpt=/dev/parport0 --upload if=avrledtest.hex -v*3 --hash=32

and now I can work !!!

But, I can spécify that the cable between computer and µC measure more 1,5 meter, and I have not any problem.
From: Paulo <psilva(at)> [ date: 2003-03-07 ]
Hi Guido!!
This article is the best I found, for beginner to AVR.
I was looking for a material to begin my project with avr atmega161, now I found it.
This hardware and software work with atmega161?
If I lock microcontroller, the uisp program may unlock it again?
Thank you, you did a good work.


From: zhangzhao <zz112233(at)> [ date: 2003-05-07 ]
i am glad to find some information
From: zwl <wl(at)> [ date: 2003-06-18 ]
dood,very good!

From: edith <edith.andrez(at)> [ date: 2003-07-14 ]
I am trying to realise this good project with AT Mega 8 and Red Hat 9.0.

But ha problems to unzip binutils-2.11..., and for use gcc-core.

Perhaps is it too old version for RedHat9.0. If it is so, please can you send to me the new versions.

From: Gonzalo Rojas <gonra(at)> [ date: 2003-08-02 ]
I probe last gcc(3.3) & binutils(2.14) to upgrade my avr-compiler, but it fails!
Now, when i compile sample program avrledtest it says:

>[gonra@localhost avrledtest-0.1]$ make
> avr-gcc -mmcu=at90s4433 -Wall -Wstrict-prototypes -Os -mcall-prologues -o > avrledtest.out -Wl,-Map, avrledtest.o
> avrledtest.o(.text+0x1e): In function `main':
> : referencia a `__stack' sin definir
> avrledtest.o(.text+0x20): In function `main':
> : referencia a `__stack' sin definir
> make: *** [avrledtest.out] Error 1

Someone had same trouble??
From: David Green <kdgreen(at)fastmail_dot_fm> [ date: 2003-08-06 ]
gcc (3.3) has a problem with the stack pointer. It can be fixed by passing the address of RAMEND to the linker or, what i eventually did, get the gcc (3.3.1) beta in which a nice soul has fixed the problem (something to do with weak types). this gcc works with AT90S2313, AT90S8535 and ATMEGA128.

The latest newlib and binutils seem to be fine.

For the 2313 the following change to the Makefile defines the initial stack pointer when using gcc(3.3):

avrledtest.out : avrledtest.o
$(CC) $(CFLAGS) -Wl,--defsym,__stack=223 -Wl,-Map, -o avrledtest.out avrledtest.o


From: Philippe <mail(at)> [ date: 2003-09-06 ]
Ich würde gerne wissen, wie man für den AVR Microcontroller
Interrupts programmiert. Interrupts sind mir von der theorie her geläufig,
habe aber noch nie einen Programmiert (nur scheiß polling betrieb.

Wäre super cool, wenn jemand einen Link zu einem Listing mit Interrupts für den
AVR hat, oder sonstige Datenblätter zum Thema Interrupt!!!

Vielen Dank und viel Spaß noch!!

From: guido [ date: 2003-09-06 ]
Hi Philippe,
just have a look at any of the articles later on in this
series. They all use interrups.

From: John McKown <john_mckown(at)> [ date: 2004-02-09 ]
Great article! Here's a project to use it on: build yourself a one-hand, wearable, chording keyboard. Open source code and instructions are at
From: Eric Duplain <sonikman(at)> [ date: 2004-02-22 ]
Hi Guido, really good article,
I got the Led blink, but now I'm unable to erase the programs in the chip.
I'm using Linux Red Hat 9.0 and uisp version 20030618
I'm writing this command
uisp -dpart=at90s4433 -dlpt=/dev/parport0 --erase -dprog=dapa

And it then reply me as if it was working but the Led is still blinking

Atmel AVR AT90S4433 is found.
Erasing device ...
Reinitializing device
Atmel AVR AT90S4433 is found.

I had no problem uploading the .hex file. Anybody can help me???
From: Guido Socher [ date: 2004-02-23 ]
Hi Eric,
I have never tried to only erase. Erase and then overwrite
with a different program. I am sure it will work.
From: alula [ date: 2004-03-02 ]
I try it with ATmega8L, ATmega8L has the same pin with at90s4433(reset,vcc,gnd,xtal1,xtal2,pb5,p4,pb3,pd5),I use avr-gcc 3.3.2 as old version don't support atmega8, but when I make load, it say:

uisp -dlpt=/dev/parport0 --erase -dprog=dapa
An error has occurred during the AVR initialization.
* Target status:
Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff

Probably the wiring is incorrect or target might be `damaged'.

I check my circuit it's ok!
any ideas?

From: Wojciech [ date: 2004-03-06 ]
This site is a piece of very good useful work.
From: Tim <tfs4(at)> [ date: 2004-04-01 ]
I am running a default slackware 9.1 installation. I have tried many different versions of gcc-core and binutils, and i still get the same error, it follows:

I./. -I./config -I./../include -DL_mulqi3 -xassembler-with-cpp -c ./config/avr/libgcc.S -o libgcc/./_mulqi3.o
config/avr/libgcc.S: Assembler messages:
config/avr/libgcc.S:72: Error: suffix or operands invalid for `clr'
config/avr/libgcc.S:72: Error: no such instruction: `clear result'
config/avr/libgcc.S:74: Error: no such instruction: `sbrc r24,0'
config/avr/libgcc.S:75: Error: too many memory references for `add'
config/avr/libgcc.S:76: Error: too many memory references for `add'
config/avr/libgcc.S:76: Error: no such instruction: `shift multiplicand'
config/avr/libgcc.S:77: Error: no such instruction: `breq __mulqi3_exit'
config/avr/libgcc.S:77: Error: no such instruction: `while multiplicand!=0'
config/avr/libgcc.S:78: Error: no such instruction: `lsr r24'
config/avr/libgcc.S:79: Error: no such instruction: `brne __mulqi3_loop'
config/avr/libgcc.S:79: Error: no such instruction: `exit if multiplier=0'
config/avr/libgcc.S:81: Error: too many memory references for `mov'
config/avr/libgcc.S:81: Error: no such instruction: `result to return register'
make[2]: *** [libgcc/./_mulqi3.o] Error 1
make[2]: Leaving directory `/home/downloads/AVR/gcc-3.0.3/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/downloads/AVR/gcc-3.0.3/gcc'
make: *** [all-gcc] Error 2

i have added the /usr/local/atmel/bin line, and followed all the instructions to the letter. has anyone else ran into this problem/know how to fix it?

From: Tim <tfs4(at)> [ date: 2004-04-01 ]
i got the gcc thing fixed, but now i have a uisp error:
Main.C: In function `const char* GetCmdParam(const char*, bool)':
Main.C:123: default argument given for parameter 2 of `const char*
GetCmdParam(const char*, bool = true)'
Global.h:105: after previous specification in `const char* GetCmdParam(const
char*, bool = true)'
Main.C: In function `const char* GetCmdParam(const char*, bool)':
Main.C:124: `strlen' undeclared (first use this function)
Main.C: In function `bool Info(unsigned int, const char*, ...)':
Main.C:147: `va_list' undeclared (first use this function)
Main.C:147: syntax error before `;' token
Main.C:148: `ap' undeclared (first use this function)
Main.C:148: `va_start' undeclared (first use this function)
Main.C:150: `va_end' undeclared (first use this function)
make: *** [Main.o] Error 1

From: briceg [ date: 2004-07-27 ]
Great article. Here are a few notes on the installation I did with the latest and greatest software.

binutils-2.15 gcc-core-3.4.1 avr-libc-1.0.4 uisp-20040311 simulavr-

Processor is an Athlon 3200XP and the OS is a Fresh copy of Fedora Core 2.

Here are a few notes:
GNU binutils:
no changes to the instructions

AVR gcc:
Before you make, set your path to include /usr/local/atmel/bin
export PATH=/usr/local/atmel/bin:$PATH

AVR C-library:
The libc I used (1.0.4) include doconf and domake.
go ahead and do the exports. Then use:
./doconf --prefix=/usr/local/atmel --target=avr --enable-languages=c --host=avr
./domake install

Do a top level ./configure and make. If it fails, try a make clean and then another make.

I also installed the simulavr. Do the ./configure, and then edit the test_asm/test_8515/Makefile and replace the occurance of avr85xx with avr2. Then make, make check and finally, make install.
From: Garratt <garrgall(at)> [ date: 2004-09-16 ]
Hi Guido!

I'm having troubles with programming my microprocessor. I'm using uisp, and
it recognizes my chip, or at least for the first operation I perform.
>make load
uisp -dlpt=/dev/parport0 --upload if=avrledtest.hex -dprog=dapa -v=3 --hash=32
Reset inactive time (t_reset) 1000 us
AVR Direct Parallel Access succeeded after 31 retries.
Vendor Code: 0x1e
Part Family: 0x92
Part Number: 0x03
Atmel AVR AT90S4433 is found.
Page Write Disabled
FLASH Write Delay (t_wd_flash): 11111 us
EEPROM Write Delay (t_wd_eeprom): 11111 us
Uploading: flash
(total 140 bytes transferred in 0.80 s (176 bytes/s)
Polling: count = 139, min/avg/max = 3.34/4.03/12.75 ms

However, after I execute either erase or load (I seperated the two commands in the makefile), when executing all subsequent operations I get this:

>make erase
uisp -dlpt=/dev/parport0 --erase -dprog=dapa
Cannot identify device because it is locked.
Device similar to the ATmega103-old is found.
Erasing device ...
Reinitializing device
Cannot identify device because it is locked.
Device similar to the ATmega103-old is found.

>make load
uisp -dlpt=/dev/parport0 --upload if=avrledtest.hex -dprog=dapa -v=3 --hash=32
Reset inactive time (t_reset) 1000 us
AVR Direct Parallel Access succeeded after 0 retries.
Vendor Code: 0x00
Part Family: 0x01
Part Number: 0x02
Cannot identify device because it is locked.
Device similar to the ATmega103-old is found.
Page Write Disabled
FLASH Write Delay (t_wd_flash): 61111 us
EEPROM Write Delay (t_wd_eeprom): 11111 us
Uploading: flash
#Device is locked.
Address out of memory range.
make: *** [load2] Error 3

I tried downloading the flash memory, (unplug cable, plugin cable, then download)
and I found it to be completely blank.

The board I'm using is a premade one, schematic:
and all the connections are the same as on your schematic, except for the 470 ohm resistors and the 8mhz crystal.

basically it boils down to two symptoms:
1) any interaction with the input line makes the locking bits go low,
preventing any reading or writing to the chip. the "uisp --lock"
command seems useless.
2) unplugging the input line and plugging it back in causes everything,
including the locking bits to reset

any ideas what could be wrong? / things I could test?

thanks a bunch
From: Garratt [ date: 2004-09-19 ]
hold up! before anyone reads the above post and scratches their head raw and bloody, I found a solution!!

first of all, I used a different avr programmer. this one has TONS more documentation, and really works amazingly. it's called sp12, and is available from:

BUT: don't be an idoit like I was, and just assume you can use the same connection to your parallel port.
I was going half mad before my friend Dave, (he's just great) actually looked at the instructions and fixed me up.
Morale: read the instructions! they aren't very long at all.
I'm using linux, and the command I used to load was:

sp12 -wpfC avrledtest.hex

but you really should read the command line arguements yourself. they're located in sp12.txt

there. problem solved.

Thanx guido, for such a great idea and for getting me started in the world of robotics!
also thanx Dave,
and the makers of that great program sp12!

this program is available for macs, windows, and linux

note: I didn't connect the "power" from the parallel port as indicated, because I was using onboard power. This was not a problem.

From: hanes [ date: 2004-09-21 ]
From: Afshin <a_joooshesh(at)> [ date: 2006-08-18 ]
i want to program AVRuc with USB bus, could you please help me?
and how the schematic is?

67 talkbacks in English
Other talkbacks:   Italiano Deutsch Francais

Due to the increased amount of web spam we have deciced to removed the talkback posting possibility. You can read old talkbacks but you can no longer post new ones.

Back to

Please contact webmaster(at) if you have any questions with regards to this talkback

lftalkback version 3.10