Have I nuked it?

Just got a Duemilanove... Environment is 100% Linux command-line. (It works for me for all other projects I do) Yesterday I managed to get blink going on it - lots of compiling, linking by hand and eventually getting avrdude to upload the hex file, (57600 baud!!!) and blink was running just fine.

Today I tidied things up - make libraries, Makefiles and so on. Re-compiled blink and uploaded it... But now instead of a nice one blink a second, the LED is blinking rather rapidly - 5 times a second or more )-:

Worse, I can't upload anything into it anymore. After a reset (manual or via command), it instantly starts it's high-speed flashing again.

Is it possible that it's somehow deleted/corrupted the bootloader? avrdude output matches that of others I've seen posted, so it seemed to upload OK.

Next stage is to order a programmer and see if I can re-flash it, but just wondering if this has happened to anyone else?

If it's set up right you shouldn`t be able to delete / corrupt the boot loader, but the truth is you can very easy.
It's not the first time I've needed my programmer to put it back.

Has happened to anyone else? Yes too often.

Yeah something similar just happend to me. Sadly it can and does happen. You can sometimes get it to pay attention by plugging it in and out but on occation that wont work. You'll need to reprogram the bootloader using a number of different ways (ISP, Bitbang, hotswap etc)

I use a AVRISP mkII .
Not cheap , but gets the job done.

Hmm. I've got exactly these symptoms as well just now.

So putting it back takes specialized hardware beyond just a USB cable?

Pity the chip itself doesn't come with a reset or clear switch or something?

Curiously, I was in exactly the same stage of cleaning up Makefiles and
the like when I got this. I figure if I can just get it talking on the
serial port... but so far no luck adapting the smiley micro stuff to the
latest avr-libc and such... has anyone out there just finished this
process and is ready to do printf-style debugging of some sort given a
fully modern linux environment?

Well just to update - made myself a parallel programmer cable from the instructions here:

got the bootloader .hex file from the German site and off it went. Programmed and verified using the versatile avrdude.

Then tried to upload my own thing and it did the same again. Lather risen repeat. (Both directly and via the usb/serial bootloader)

So I suspect I've got something wrong in my libraries and/or build process, so back to the drawing board.

Maybe I should have stuck to using the IDE, but I'd much prefer to use the command-line stuff I've been used for for the past umpteen years...

Ta!

Hi, to likely confuse you.

Did you set the right fuse bits?
Because the fuse bits sets how the chip works, and if there is a boot loader or not.

Hi,

Didn't touch the fuse bits, but I seem to have sorted it all out now, thanks.

So standard file editing, makefile compiling and uploading all sorted now. I might even publish this at some point - basically compiled everything in the release cores/arduino directory (from the 0017 release) into a .a file then link that into my own program. I needed to fiddle with the compiler flags to get it all right, and I can now upload my programs via the USB/Serial mechanism, or directly via the parallel port programmer. Should be able to link in other libraries too - such as Ether/LCD, etc.

Cheers!

By the way someone who can edit the arduino site should change this
page:

http://arduino.cc/en/Hacking/CommandLine

as it gives a download of a pretty old arduino core (0011) that doesn't
play well with the recent avr-libc.

It might be bett on this page to just give instruction where to find the core stuff in the regular download.

I also have a Duemilanove, and I think I've got the same problem. I went through a lot of tries to upload using different parameters in avrdude and I think I could have killed the bootloader.

command:
avrdude -p m328p -P /dev/ttyUSB0 -c stk500v2 -E reset -F -U flash:w:main.hex -b 57600 -v -v -v -v

it boils down to this:

avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

As far as I can tell these are the parameters that are supposed to work for duemilanove - are they? It could be I'm just doing it wrong. Could my avrdude.conf being incorrect have corruped my bootloader? I downloaded the atmega328p for avrdude.conf section from a blog somewhere, and it seems to differ from the atmega328 bit in file ./build/linux/dist/tools/avrdude.conf in SVN on google code. Could this have clobbered my bootloader?

I'm thinking of using the parallel port programmer described in earlier posts to fix my bootloader, it's confirmed to work on duemilanove yes?

I think you're using the wrong format - here's the command I'm using for my 2009 board:

avrdude -C /usr/local/arduino/hardware/tools/avrdude.conf -p atmega328p -P /dev/ttyUSB0 -c stk500v1 -b 57600 -U flash:w:$(TARGET).hex

Note stk500v1 and not v2 which you have...

You may also need to reset your board immediately before doing that although it looks like the latest avrdude seems to do this, but if not, then this bit of perl will work:

use Device::SerialPort;
Device::SerialPort->new("/dev/ttyUSB0")->pulse_dtr_on(100);

Building the programmer wasn't hard though, I had everything I needed in my junk box, but your junk box might be cleaner than mine :wink:

Good luck..

Thanks dude! Your avrdude command worked after I used your perl.

Also, the most recent avrdude has an aruino programmer ID:

-c arduino

I sort of suspect I nuked mine by using a wrong programmer ID. It seems like using a wrong enough programmer might cause avrdude to not know about the bootloader code and upload over it or something. But thats only a guess based partly on what I was doing with the Makefile at the time.

Self-answered question:

Question: Which .hex file from the arduino-0017.tgz is the one to use to repair
a nuked bootloader for the arduino duemilanove hardware
(http://arduino.cc/en/Main/ArduinoBoardDuemilanove)?

Answer: Probably
arduino-0017/hardware/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex

Not that I've tried it yet. Reasoning:

In the 0017 download, I get this:

rhino$ find . -name "*.hex" -print
./hardware/bootloaders/lilypad/LilyPadBOOT_168.hex
./hardware/bootloaders/atmega/ATmegaBOOT_168_diecimila.hex
./hardware/bootloaders/atmega/ATmegaBOOT_168_ng.hex
./hardware/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
./hardware/bootloaders/atmega/ATmegaBOOT_168_atmega1280.hex
./hardware/bootloaders/atmega/ATmegaBOOT_168_pro_8MHz.hex
./hardware/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex
./hardware/bootloaders/atmega8/ATmegaBOOT.hex
./hardware/bootloaders/bt/ATmegaBOOT_168.hex
rhino$

The file 'ATmegaBOOT_168_atmega328_pro_8MHz.hex' looks closest, but the
hardware page for arduino says its 16 MHz.

But looking in /hardware/bootloaders/atmega/Makefile it looks like
./hardware/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex is a 16 MHz version.
I'd say if there is going to be one called with _8MHz suffix, the other should
have _16MHz maybe...

Britton

I now have a programmer, avrispmkII. But when I plug it in, not /dev/ttyUSB0 springs into existence as happens with the arduino.

Even if it did I guess I'd still need to do something else, since the arduino board needs to be plugged into USB as well for power. Perhaps they would compete for /dev/ttyUSB0 :slight_smile:

I guess i need to soemthing with udev. Has anyone already been down this road?

In terminal (command prompt) type

dmesg|tail

just after you've plugged the programmer in. It will give you some clues.

If its a similar serial device to the arduino, ttyUSB1 would seem likely. You don't usually need to mess with udev unless you need it to be called the same every time.

To answer my own question again, in case anyone else is digging out
of this same hole:

For the arduino, one uses -P /dev/ttyUSB0, but for the avrispmkII (and
probably its close friends too) one instead uses '-P usb', and makes sure
the avrdude binary is setuid root. I believe a library called something like libusb or so (on linux) is involved as well, not sure how standard it is.

Now the .hex file mentioned previously can indeed be programmed with the avrispmkII, regardless of the condition of the bootloader.

The exact commands to use to do this can be found in

arduino-0017/hardware/bootloaders/atmega/Makefile

in the

$(ISPFUSES)
$(ISPFLASH)

make variables. Note that these variables themselves use a bunch of
target-localized make variables particular to the board, processor,
and frequency being used. For the Duemilanove, the atmega328_isp
is the one we want.

Whew, back to square one finally :o

Is it an ICSP programmer? I would consider wiring up a power adapter rather than sort ouf the software issues that are getting in your way.

I have to admit... I'm kind of lost with this discussion. The Arduino solution pretty much does its best to isolate the user from having to deal with things like custom "make" files and such.

Seems to me that if you want the extra bits to fiddle with you might as well lose the Arduino bootloader and just program the unit with straight AVRGCC.

I've had good results with LADYADA's USBtiny avr programmer... I've used the cheapo parallel solution, but it never really felt very safe to use.

You may have a point. I've got avr-gcc and avrdude doing the job but using the ladyada bootloader. I'm not that good with embedded work (this is the first I've done since lego mindstorms), though.

Since the bootloader and library (which, granted, may not be very good) are supposed to work with the hardware, it's one less variable to worry about.