Go Down

Topic: Bootloader unable to program FLASH (i.e. upload sketch)? (Read 3 times) previous topic - next topic

chrissv

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

westfw

Quote
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"...

chrissv


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: [Select]

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

chrissv

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

chrissv


Go Up