Go Down

Topic: Bootloader only works once? (Read 2 times) previous topic - next topic

westfw

Quote
There's nothing wrong with the hardware.  The programmer operates just fine.  The programmed part also works - it takes a sketch download *once*.  Subsequent tries fail.

It still sounds to me like you're not having RESET get  you back to the bootloader, or aren't staying there long enough for avrdude and the bootloader to start talking.   Are you sure  your reset button works?  (as your first sketch, try downloading something that behaves differently at the beginning than after running for a while.)

Can you get a memory dump of the programmed AVR ?  (with bootloader only, and then with bootloader and sketch?)  This should tell you whether you're overwriting the bootloader with the sketch...  (although I didn't think that that was possible.)  (The tutorial here: http://www.arduino.cc/playground/Code/OSXISPMKII does suggest that you need to lock the bootloader AFTER it is downloaded, which I don't see in your original message.)

You ARE doing things well outside the realm of what most people in the Arduino community are doing.  While I consider myself unusually knowledgeable about the low level AVR details, I've only used my STK500 to reprogram a bootloader ONCE.  And I used the Arduino IDE to do it, I think...  That's why avrfreaks was suggested as a resource.


raron

#16
Mar 18, 2010, 09:40 pm Last Edit: Mar 18, 2010, 09:42 pm by raron Reason: 1
I agree with retrolefty, I think it's the missing lock bits. No lock bits = boot loader section not protected from being overwritten. Actually I'm surprised it can overwrite itself with a new sketch before stopping to work.

I'm by no means an expert in this myself. I've only done this once too (on some atmega 328's, one of which I think I bricked), and its half a years since already. I made some notes then though. Basically, fuse and lock bits settings for an atmega 328P at 16Mz with an external resonator, SPI programming enabled and a 2 kB (1k word) boot loader is:

L fuse: 0xFF
H fuse: 0xDA
E fuse: 0xFD

And the boot loader lock bits: 0xCF

No guarantee of the correctness, though.

As for the different efuse, I think it's the same thing, the 5 first bits are not used (0x05 vs 0xFD, also see table 25-6,page 296 of the atmega 44/88/168/328 datasheet). But it might have something to say with verify errors (which I got, but it seems to work nevertheless). Something to do with "1" being "unprogrammed", and "0" being "programmed". And probably it reads back "0" for unused bits (but I'm not sure about that).

While I'm at it, I'd like to recommend the modified ADABOOT: http://www.wulfden.org/TheShoppe/freeduino/ADABOOT.shtml It's really quick, starts sketched almost instantly. And its for atmega 168/328 and 644 (I've only tested 328 so far, but I'm going to test 644 soonish).

Gene Buckle

I've since discovered that adding:

-U lock:w:3F:m to the avrdude command line before the flash write and
-U lock:w:0F:m to the avrdude command line after the flash write cures the problem.

tnx.

g.

retrolefty

#18
Mar 18, 2010, 11:49 pm Last Edit: Mar 18, 2010, 11:50 pm by retrolefty Reason: 1
Quote
I've since discovered that adding:


Kind of reminds me of my very first posting response to your question/problem.  :P

Lefty

vxir

If you are still stuck, I will give you everything I use: exact avrdude commands, fuse bit files, and boot rom.  You can try it to see if it works.

Gene Buckle

Lefty: without context it didn't help.

vxir: Thanks.  I think have it pretty well nailed down, but I'll keep you in mind if it goes pear shaped on me again. :)

tnx.

g.

retrolefty

Quote
Lefty: without context it didn't help.


And you sir, are rude, IMO.

Lefty

Gene Buckle

Without a doubt.

I'm also intolerant of vague answers that assume knowledge.  I assure you, it's not the least of my flaws.

g.

dramida

bootlock12 and bootlock11 fuses must be set to deny writing in boot area from the end of memory, also bootrst must be set to start executing instruction from the boot area.


Gene Buckle

Thanks for the reply dramida.  I did get it working some time ago - I found I was fighting on two fronts - a bad '328 and wrong lock bits. :)

g.

mellis

Let's try to keep things civil, please.  

Go Up