next topic »

[Reply #15 on:]

I believe that you have to use the -e option which also erases the fuses when you program the
flash.
http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions
Do you know the value for your 644 fuses?

I'd update the Makefile to include a rule to burn the flash to avoid
typing in the long command line.

I've updated my  arduino AmetaBOOT makefile to support doing all this in one avrdude command
for the Dragon as the current avrdude has a bug in it such that back to back avrdude commands
will fail on the dragon. (I also have a patch for that but the avrdude maintainer refuses to accept
it - but that is another story).

Here is the definition that I use:

Code:

# enter the parameters for the avrdude isp tool
ISPTOOL = dragon_isp
ISPPORT   = usb
ISPSPEED =

# the efuse should really be 0xf8; since, however, only the lower
# three bits of that byte are used on the atmega168, avrdude gets
# confused if you specify 1's for the higher bits, see:
# http://tinker.it/now/2007/02/24/the-tale-of-avrdude-atmega168-and-extended-bits-fuses/
#
# similarly, the lock bits should be 0xff instead of 0x3f (to
# unlock the bootloader section) and 0xcf instead of 0x0f (to
# lock it), but since the high two bits of the lock byte are
# unused, avrdude would get confused.

ISPFUSEFLASH = avrdude -c $(ISPTOOL) -p $(MCU_TARGET) -P $(ISPPORT) $(ISPSPEED) \
-e -u -U lock:w:0x3f:m -U efuse:w:0x$(EFUSE):m -U hfuse:w:0x$(HFUSE):m -U lfuse:w:0x$(LFUSE):m \
-U flash:w:$(PROGRAM).hex -U lock:w:0x0f:m

This single command was a modification of their existing fuse burning methodology.
When using the dragon you can remove the initial "-U lock:w:0x3f:m" as it is not needed.
Not sure if other programmers need it as some of them ignore the erase
command and only erase things when new data is written.

You will need to define EFUSE, HFUSE, and LFUSE
I assume the 644 has 3 fuses? and I'm not sure what those are or
what the final lock bits need to be for that part.

you will then need a rule to to the actual burn.
Something like this near the bottom of the makefile:

Code:

program: $(PROGRAM).hex
$(ISPFUSEFLASH)

You can then do "make program" to program the part.
Make sure you use a <TAB> in the program rule above rather than spaces
as make after 35+ years still requires tabs rather than whitespace as lead in separators.

[Reply #16 on:]

Actually -e on avrdude may not erase the fuses, but it definitely erases the lock bits.
I've always set the fuses at the same time using the -u option so I'm not really sure.

You might be able to just use the -e option on what you had and then set the lock bits
when done and not have to mess with the fuses.

--- bill

[Reply #17 on:]

I managed to burn the bootloader through AS5.

But, now, trying to upload the sketch, I get this error:

Binary sketch size: 11082 bytes (of a 63488 byte maximum)
avrdude: verification error, first mismatch at byte 0x0002
         0x7a != 0x38
avrdude: verification error; content mismatch

Why?

Jan

[Reply #18 on:]

What about the fuses & lock bits?
Were they restored when the bootloader was burned?

[Reply #19 on:]

I can check that. What should they be?

Jan

[Reply #20 on:]

I don't know about fuses/lockbits on a 644
I have never looked at the manual for the 644 to see if/how they differ from the 328.

Given that it is location 2, it sounds like the very first flash block failed to be
written. Maybe the lock bits are not set correctly to allow updating the application.

If you look at the hex image for the sketch, what is in the first few bytes?
Do you see a 0x7a or a 0x38 down there?

If you go back to the original bootloader, does the upload work?
If it is a lock bit issue, then the original bootloader won't work either
until the lock bits are set correctly.

--- bill

[Reply #21 on:]

Using the original bootloader I was able to upload an sketch.
But this means I'm back to square one. So, what next?

Jan

[Reply #22 on:]

Is this older bootloader one that you built? Or a binary they someone else built?
I have noticed that there are cases (including in the official Arduino releases) where
the binary bootloaders shipped do not match the source code that was shipped.
i.e. they are not building the bootloader binary they are shipping from the source code that they are shipping.

I can take a look at the code if you can supply some additional information.
Can you supply a set of diffs between what works and the one that now no longer works?
Or better a zip/rar of the two different build trees?
(full source and makefiles used to build both the working image and the non working image)



--- bill

[Reply #23 on:]

The one that works: http://code.google.com/p/sanguino/downloads/detail?name=Sanguino-0018r2_1_4.zip&can=2&q=(ATmegaBOOT_644.hex)
bootloader.zip and atmega644p.zip both contain bootloaders that to not work (both with changes you sad to me to do to the code).
bootloader.zip is compiled using AS5 and uploaded without problems but gave the verification error then trying to upload a sketch.
atmega644p.zip is compiled using the modified makefile. Uploading via avrdude gave an error about the file being of wrong type and uploading via AS5 gave some error about to large sections or similar.

Jan

[Reply #24 on:]

I noticed that you changed the processor type in the Makefile
from "atmega644p" to "atmega644"
Why did you change that? (sorry if I confused you on this)

The makefile in bootloader.zip created by AS5 looks like it also was using 644 vs 644p

The boot loader has a signature hard coded into it (rather than reading it from the actual chip)
It is different for 644 vs 644p
The Sanguino boards.txt uses 644p which controls the cpu type used for the ARDUINO IDE sketch builds
and more importantly avrdude uploads.
If these mismatch, you will get a signature mismatch type error from avrdude when attempting to upload your
sketch using the IDE.
So building the bootloader code as "644" and sketches as "644p" won't work.
They both must match.
Since the boards.txt file uses 644p make sure to build the bootloader as 644p so
it matches.

Fixing the processor type will fix the signature errors
so we can see if there are any additional issues that need to be addressed.


I also noticed that the fuse setting variables were missing from the updated makefile.
If you want to use the makefile to burn the bootloader, you will need to fill
in the fuses in the makefile.
Here they are using values from your sanguino boards.txt file.
Add these lines to the Makefile just below the ISPxxx variables.

Code:

LFUSE = 0xFF
HFUSE = 0xDC
EFUSE = 0xFD

--- bill

[Reply #25 on:]

Well, to make clear, I'm using an 644 (non p), and I have a modified boards.txt file (attached) wich includes the 644.

[Reply #26 on:]

Seems the bootloader from the sanguino site has ADABOOT defined or similar, atleast bperrybap's sketch works.
To bad I didn't test earlier.

Thanks everybody,
Jan