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.
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)
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?
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.
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.
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?
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
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.
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...
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
I guess i need to soemthing with udev. Has anyone already been down this road?
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.
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.