Burning the bootloader directly via avrdude

Re: Burning the bootloader directly via avrdude

Lsutehall — Tue, 11 Oct 2011 13:13:17 -0400

Yup this was windows xp, although the process should be similar on other windows systems.

The sequence of operations should work for all o/'s though.

Re: Burning the bootloader directly via avrdude

DeuxVis — Tue, 11 Oct 2011 09:10:29 -0400

mmadore Wrote:
-------------------------------------------------------
> What OS is this done from?
>

Looks like windows XP from the screenshots on his blog.

Re: Burning the bootloader directly via avrdude

mmadore — Tue, 11 Oct 2011 08:37:57 -0400

What OS is this done from?

Lsutehall Wrote:
-------------------------------------------------------
> I finally managed to burn the bootloader. I used a
> different set of instructions to that above,
> mainly because it wouldn't all fit into the
> command line. Here is what I used:
>
>
> avrdude -c avrispmkii -p m644p -P usb48 -B 8 -u -e
> -U lock:w:0x3F:m -v
>
> avrdude -c avrispmkii -p m644p -P usb48 -v (used
> to check if chip signature is now correct)
>
> avrdude -c avrispmkii -p m644p -P usb48 -u -U
> efuse:w:0xFD:m -v
>
> avrdude -c avrispmkii -p m644p -P usb48 -u -U
> hfuse:w:0xDC:m -v
>
> avrdude -c avrispmkii -p m644p -P usb48 -u -U
> lfuse:w:0xFF:m -v
>
> avrdude -c avrispmkii -p m644p -P usb48 -U
> flash:w:ATmegaBOOT_644P.hex -v
>
> avrdude -c avrispmkii -p m644p -P usb48 -U
> lock:w:0x0F:m -v
>
>
> Full details of what I did can be found in a
> dreadfully long post here: foraysinto3d

Re: Burning the bootloader directly via avrdude

Lsutehall — Fri, 23 Sep 2011 14:51:02 -0400

I programmed my chip in the order I gave above, thus setting the fuses in the middle of the sequence. I did however encounter the "incorrect device signature" error, hence the "-B 8" switch on the first line. I also suppressed avrdude's default behaviour of checking the fuses 3 times before doing anything.

I have been testing the axis motors today, and they all work ok. the order I set the fuses in appears not to have mattered.

Re: Burning the bootloader directly via avrdude

marnargulus — Fri, 23 Sep 2011 14:00:47 -0400

I'm going through my archives of old Arduino/Sanguino discussions and found an interesting item of import, can anyone out there verify?

(from a hackaday comment)
Coda says:
August 17, 2011 at 12:00 pm
It’s not a bug, and it’s nothing to do with arduino, or even Atmel, the ‘issue’ is common to most embedded platforms. The fuses are always the last thing you program, especially if you’re changing oscillator options from defaults (I learned this myself the hard way, and had to wait for an oscillator to arrive in the post) and any ATMega/Tiny chip will lock you out if you don’t follow the right programming order.

It’s handy to have a couple of spare oscillators lying around (8,12,16mhz etc and they are not expensive) even if the project that you’re building doesn’t need one, (i.e you’re relying on the inaccurate internal clock – and that’s fine for a lot of applications).

So my question is:

I've talked to some people who said "The only way I got it to work was setting the fuses FIRST"
Where this comment is basically saying "The only way I got it to work was setting the fuses LAST"

So who is right? This changes the order for the dapa guide.

Re: Burning the bootloader directly via avrdude

Traumflug — Fri, 23 Sep 2011 05:38:39 -0400

Quote

Also, am I correct in writing the bootloader to the chip's flash, or should I be writing to the boot section?

Both :) The boot section is part of the chip's flash. Where this bootloader section is (usually the last 2 kB) is encoded in the bootloader's hex file.

Re: Burning the bootloader directly via avrdude

fteo88 — Thu, 22 Sep 2011 20:34:06 -0400

Using avr MKII as your ISP? Congrats.

Re: Burning the bootloader directly via avrdude

Lsutehall — Thu, 22 Sep 2011 18:14:27 -0400

I finally managed to burn the bootloader. I used a different set of instructions to that above, mainly because it wouldn't all fit into the command line. Here is what I used:

avrdude -c avrispmkii -p m644p -P usb48 -B 8 -u -e -U lock:w:0x3F:m -v

avrdude -c avrispmkii -p m644p -P usb48 -v (used to check if chip signature is now correct)

avrdude -c avrispmkii -p m644p -P usb48 -u -U efuse:w:0xFD:m -v 

avrdude -c avrispmkii -p m644p -P usb48 -u -U hfuse:w:0xDC:m -v 

avrdude -c avrispmkii -p m644p -P usb48 -u -U lfuse:w:0xFF:m -v 

avrdude -c avrispmkii -p m644p -P usb48 -U flash:w:ATmegaBOOT_644P.hex -v 

avrdude -c avrispmkii -p m644p -P usb48 -U lock:w:0x0F:m -v

Full details of what I did can be found in a dreadfully long post here: foraysinto3d

Burning the bootloader directly via avrdude

Lsutehall — Fri, 09 Sep 2011 08:49:49 -0400

So I've finally gotten my computer to talk to the programmer I'm using, but only via avrdude directly - the arduino software still can't find it.

I've used the examples at the bottom of this page as an example of the order in which to write each byte and have posted below what I will send to avrdude via the command line. Can anyone cast their eye over it, and see if I have made any mistakes please?

Also, am I correct in writing the bootloader to the chip's flash, or should I be writing to the boot section?

avrdude -c avrispmkii -p m644p -P usb:48 -e -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xDC:m -U lfuse:w:0xFF:m -U flash:w:ATmegaBOOT_644P.hex -U lock:w:0x0F:m

Thanks!