next topic »

[on:]

I have a Wasp board, which uses an atmega644 running at 8MHz (internal RC) - http://www.soc-machines.com/product/Chinook_Specs/Wasp.html

It came with a bootloader which works fine with the Arduino environment (after I loaded some Sanguino code files).

The problem occurs when I try to upload a different bootloader (in this case, Optiboot v3). I modified the code to account for the different LED (it is on PD5), and the fact it is an atmega644, and everything compiles correctly. I can program the bootloader (via AVR studion and AVRISP) just fine, and the led blinks like it should on reset.

From what I can tell from the output (see link below), when trying to program in the Fade sketch, it looks like the bootloader accepts the sketch FLASH data, but when it is in the verify step, it reads back all 0xFF instead of the program data. It's almost like the bootloader couldn't program the FLASH memory. Note I am running with no lock bits enabled whatsoever, and it looks like the protocol is working fine.

Here is the verbose output of my attempt to upload the sketch: http://www.c-web.us/~steven/arduino1.txt

If I program back in the original bootloader (which came with the board), I can upload this same sketch with no problems.

Does anyone have any suggestions?

Thanks - Steven

[Reply #1 on:]

I modified the code to account for the different LED (it is on PD5), and the fact it is an atmega644, and everything compiles correctly.

Did you start with the version that claims to sort-of-support the 644?  Exactly what changes did you make?  What fuses are you using, and what compile command?   The latest source I have claims that 644 is a "work in progress"...

[Reply #2 on:]

Did you start with the version that claims to sort-of-support the 644?

I used v3 which is the latest version on the google code website. I didn't see anything about it which had 644-specific code in it.

Exactly what changes did you make?

All I did was add some #ifdef's for the chip type, to set the proper LED #defines. Also, I modified the Makefile to put in the specific particulars about this build version (defining the CPU type, freq., etc.)

What fuses are you using...

I changed the boot select fuse to put the boot start address at 0x7e00 (which matches the Makefile changes I made). The fuse settings are: EXTENDED=0xFF; HIGH=0xDE; LOW=0xE2. Also, LOCKBITS=0xFF (everything unlocked).

... and what compile command?

Here is the output from the make command:

Code:

avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -mmcu=atmega644 -DF_CPU=8000000L  '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200'   -c -o optiboot.o optiboot.c
avr-gcc -g -Wall -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -mmcu=atmega644 -DF_CPU=8000000L  '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200' -Wl,--section-start=.text=0x7e00 -Wl,--relax -nostartfiles -o optiboot_atmega644_pro_8MHz.elf optiboot.o
avr-objcopy -j .text -j .data -O ihex optiboot_atmega644_pro_8MHz.elf optiboot_atmega644_pro_8MHz.hex
avr-objdump -h -S optiboot_atmega644_pro_8MHz.elf > optiboot_atmega644_pro_8MHz.lst
rm optiboot.o optiboot_atmega644_pro_8MHz.elf

As I said, the bootloader appears to function properly in all aspects, save the actual programming of the FLASH. It flashes the LED at boot, and responds appropriately to avrdude (based on what I could see in the verbose log). I am at a loss why the FLASH programming would be the thing which doesn't work...

Thanks for your help.

-- Steven

[Reply #3 on:]

OK, I solved the problem.

Some searching on AVRFreaks found another person with the same problem.

I got tripped up by the addressing in AVRStudio, the reported start address of "7E00". This is in words, not bytes.
I changed the .text section start address to 0xFC00 (which is the byte equivalent of the word address 0x7E00) and it works flawlessly.

Thanks for everyone's help!

-- Steven

[Reply #4 on:]

Oh, I guess I should mark this as [solved]!

[Reply #5 on:]

I used v3 which is the latest version on the google code website. I didn't see anything about it which had 644-specific code in it.

The latest .zip file is v3, but if you get source direct from the mercurial  tree, it's somewhat newer and includes Sanguino support (also mega8, which is somewhat more strongly different.)  (Sanguino apparently still has the startup LED on portd, so you'd still need some patches, but it would have had the right start address and fuse values...

I changed the .text section start address to 0xFC00  and it works flawlessly.

Great!  I'm not sure I want to spend any time figuring out exactly why it was behaving the way it was with the bootloader in the middle of memory (with "no" lock bytes it should still have been able to write flash, right?)  But it's clear that something would be likely to go wrong...

[Reply #6 on:]

You wrote
"It came with a bootloader which works fine with the Arduino environment (after I loaded some Sanguino code files)."

Can you be specific? I have a 644 also but there are some IDE files missing when I try to compile when I have selected the Sanguino Board as the target. Things like OUTPUT, HIGH and LOW are not defined when I compile.

What is missing?

[Reply #7 on:]

I followed the instructions on the Sanguino web page: http://sanguino.cc/softwareforwindows
and it worked as advertised.

[Reply #8 on:]

Would you share your changes to the optiboot files and the boards.txt file, etc?

[Reply #9 on:]

I assume from your lack of reply that the answer is no.

Does anyone else have a 644 bootloader for an 8Mhz mega644 and mega644P?

[Reply #10 on:]

I assume from your lack of reply that the answer is no.

Sorry, I'm not ignoring your request. I had some other personal matters jump to the forefront, but I have bookmarked this request and am still planning on responding.
 

[Reply #11 on:]

Thanks. No problem.
I have tried several times to recompile the bootloaders that come with the Arduino development system and every time I get this message that it won't fit into the 644. When I compare the HEX files from the one that is in the Arduino folder with the 'same' one which is simply re-compiled, I find that it really is larger and overflows the top of memory. So I am striking out in most respects. One would think it was an easy task to compile a boot loader.

Hoping that yours will work 'as-is' so that I don't have to try to compile it.

[Reply #12 on:]

every time I get this message that it won't fit into the 644.

Did you get this patch: http://code.google.com/p/optiboot/issues/detail?id=1&can=1

[Reply #13 on:]

Thanks, that does put me one step closer.
The bootloader now fits, but it is still not responding. I have tried to send commands over the serial monitor at various baud rates, but there is nothing coming back.
still waiting on chrissv to respond with a working version. I hope it is soon.

[Reply #14 on:]

I have made some progress with this and have but one thing to overcome.
I have a bootloader that works once. I program it into a new part with all other program space erased (oxFF). Then I use the Auduino IDE to load a sketch and it does just great; loads it up and verifies and runs.
The second time that I try to upload a sketch the bootloader no longer respoonds. I see that it hesitates for a moment, then it continues to run the previous sketch. I can see that the reset line is pulled low (volt meter) and the IDE is waiting for a response from the micro that it never gets. It times out after about 30 seconds.

So, what do I look for next? I am using the same Sanguino bootloader that was mentioned at the beginning of this thread, but it is adjusted for 8Mhz. I would have thought that there was nothing else to do but get it to work at the new clock speed.