Hi
I want to use AVROSP to program an Xmega 64a3. It appears that I require an old xml file which was part of studio4. I have tried downloading it from Atmel but the zip file seems to be corrupt. Does anyone know where I can get this from, or perhaps tell me where I can find the xml file layout?
The xmega has a Avr911 compatible bootloader in it. I am looking for an easy way to allow a non programmer to update the firmware in the field. Perhaps there are Gui's or some easier way than AVROSP?
Lol - you should know:
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=112391&highlight=avr911
I have tried using AVRDude but get this error:
Connecting to programmer: .
Found programmer: Id = "SXmegaB"; type = ?
Software Version = V.1; Hardware Version = 1.v
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
The bootloader is the one from Bandtank. It uses a make file and it took me a while getting it to work in A6. (I dont know much about make files)
I am using this cmd:
avrdude -c avr911 -P com10 -b19200 -p x64a3 -U flash:w:Timing1.hex
The error you are seeing is around line 314 in this file within avrdude:
http://svn.savannah.nongnu.org/v...
So it seems that whatever you are talking with does not respond 'y' to a 'b' command.
Thanks for that. The interesting thing is that it does respond correctly to those commands if I send them one at a time. But if I send them as a string it leaves things out:
XmegaBlV11v?pS
is the rsponse to
SVvpab
which avrdude sends. You can see that it ignored the a and b.
Its almost as if the program is running to slow to respond?
What baud rate are you using? Try swapping lines 38 and 39 in serial.c to see if that makes a difference.
Change this:
while (!(Uart(MY_UART).STATUS & (1 << USART_DREIF_bp))); Uart(MY_UART).DATA = c; // prepare transmission
to this:
Uart(MY_UART).DATA = c; // prepare transmission while (!(Uart(MY_UART).STATUS & (1 << USART_DREIF_bp)));
Also, try removing line 103 from Xmega_Bootloader.c:
while (!(Uart(MY_UART).STATUS & (1 << USART_DREIF_bp)));
Regarding clawson's comment:
So it seems that whatever you are talking with does not respond 'y' to a 'b' command.
// Check block load support.
else if(val=='b') {
sendchar('Y'); // Report block load supported.
sendchar((BLOCKSIZE>>8) & 0xFF); // Top byte first
sendchar(BLOCKSIZE&0xFF); // Lower byte second
}
I committed the changes shown above to the Github repository for my bootloader. Let me know if the changes work for you please.
Thanks for the changes. Unfortunatly they did not fix the problem. In the end I attached a logic analyser to the Xmega to monitor the serial port. I could see that your bootloader responded correctly but it still did not work. After looking at the Avrdude code I noticed that it did not seem to be expecting an echo of the command it sent. I commented out that line in the bootloader and it works.
/* Main loop */
for(;;)
{
val = recchar(); // Wait for command character.
// sendchar(val);
At this point in time it goes through the program procedure but gives errors for each byte. The chip is not being programmed. I am not familier with avrdude because I just use AS6 to program the chips, so I need to do some more testing.
One thing I have not mentioned is that my xmega is a 64a3u not a 64a3. When I try change that in the make file I get an error, so I have just left in on 64a3. I am not sure if there is any difference when it comes to self programming.
Is there a way to get avrdude to write its output to a log file?
I tried 19200 and 9600 baud and got the same results.
I am using A6 with an external makefile. If i change the makefile to indicate that I am using a 64a3u then I get this error:
Error 1 'PROGMEM_PAGE_SIZE' undeclared (first use in this function) F:\Projects\Xmega_Bootloader-master\Xmega_Bootloader\Xmega_Bootloader.c 118 52 Xmega_Bootloader
This is the makefile section I changed:
############################################################################### # Makefile for the project Xmega_Bootloader ############################################################################### ## General Flags PROJECT = Xmega_Bootloader ############################################################################### # User modification section ############################################################################### # Choose one of the following MCUs: # If you have a different MCU, you will have to define the # BOOT_SECTION_START_IN_BYTES and FLASH_PAGE_SIZE_IN_BYTES for # -section-start and the number of bytes to program at a time respectively. # This information can be found in the iox....h file as BOOT_SECTION_START # and PROGMEM_PAGE_SIZE. # MCU = atxmega128a1 MCU = atxmega64a3u # MCU = atxmega64a3 # MCU = atxmega32a4 # MCU = atxmega16a4 # MCU = atxmega16d4 # Choose a baud rate for the UART. # If you need a baud rate that is not listed in this makefile, you must add # new configuration statements in config.macros.h. Remember, Xmegas start-up # with a 2MHz clock. # BAUD_RATE = 9600 BAUD_RATE = 19200 # BAUD_RATE = 38400 # BAUD_RATE = 57600 # BAUD_RATE = 115200 # Specify a pin to check for entry into the bootloader. The notation is # PORT,PIN. For example, if you wanted to use PIN 3 on PORTC, you would set # the option as C,3. Then specifiy the logic value required to enable the # bootloader code (1 = enable the bootloader if the pin is VCC, 0 = enable # the bootloader if the pin is GND). BOOTLOADER_PIN = A,7 BOOTLOADER_PIN_ON = 0 # Specify a pin to control an LED. The notation is PORT,PIN. For example, if # you wanted to use PIN 6 on PORTA, you would set the option as A,6. Then # specifiy the logic value required to enable the LED (1 = output VCC to turn # on the LED, 0 = output GND to turn on the LED). LED_PIN = B,5 LED_ON = 1 # Specify which UART to use with PORT,NUM notation. For example, UART1 on # PORTD would be D,1. UART = E,0 ############################################################################### # End user modification section ############################################################################### ## Set configuration options based on MCU model ifeq ($(MCU), atxmega128a1) BOOT_SECTION_START_IN_BYTES = 0x20000 FLASH_PAGE_SIZE = 512 endif ifeq ($(MCU), atxmega64a3) BOOT_SECTION_START_IN_BYTES = 0x10000 FLASH_PAGE_SIZE = 256 endif ifeq ($(MCU), atxmega64a3u) BOOT_SECTION_START_IN_BYTES = 0x10000 FLASH_PAGE_SIZE = 256 endif ifeq ($(MCU), atxmega32a4) BOOT_SECTION_START_IN_BYTES = 0x8000 FLASH_PAGE_SIZE = 256 endif ifeq ($(MCU), atxmega16a4) BOOT_SECTION_START_IN_BYTES = 0x4000 FLASH_PAGE_SIZE = 256 endif ifeq ($(MCU), atxmega16d4) BOOT_SECTION_START_IN_BYTES = 0x4000 FLASH_PAGE_SIZE = 256 endif TARGET = $(PROJECT).elf TARGET_BASE = $(PROJECT) CC = avr-gcc CPP = avr-g++ ## Options common to compile, link and assembly rules COMMON = -mmcu=$(MCU) ## Compile options common for all C compilation units. CFLAGS = $(COMMON) CFLAGS += -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=$(FLASH_PAGE_SIZE) -DMCU=$(MCU) -DBAUD_RATE=$(BAUD_RATE) -DMY_UART=$(UART) -DENTER_BOOTLOADER_PIN=$(BOOTLOADER_PIN) -DLED_PIN=$(LED_PIN) -DLED_ON=$(LED_ON) -DBOOTLOADER_PIN_EN=$(BOOTLOADER_PIN_ON) -DBOOTUP_DELAY=$(BOOTUP_DELAY) CFLAGS += -MD -MP -MT $(*F).o ## Assembly specific flags ASMFLAGS = $(COMMON) ASMFLAGS += $(CFLAGS) ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2 ## Linker flags LDFLAGS = $(COMMON) LDFLAGS += -Wl,-Map=$(PROJECT).map LDFLAGS += -Wl,-section-start=.text=$(BOOT_SECTION_START_IN_BYTES) ## Intel Hex file production flags HEX_FLASH_FLAGS = -R .eeprom -R .fuse -R .lock -R .signature HEX_EEPROM_FLAGS = -j .eeprom HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load" HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 --no-change-warnings ## Objects that must be built in order to link OBJECTS = eeprom_driver.o $(PROJECT).o serial.o sp_driver.o CCP_Write.o ## Objects explicitly added by the user LINKONLYOBJECTS = ## Build #all: begin gccversion build end all: $(TARGET) $(PROJECT).hex $(PROJECT).eep $(PROJECT).lss## Compile #all: sizebefore $(TARGET) $(PROJECT).hex $(PROJECT).eep sizeafter $(PROJECT).lss## Compile eeprom_driver.o: eeprom_driver.c $(CC) $(INCLUDES) $(CFLAGS) -c $<
I also had to change this to make it compile:
#all: begin gccversion build end all: $(TARGET) $(PROJECT).hex $(PROJECT).eep $(PROJECT).lss## Compile #all: sizebefore $(TARGET) $(PROJECT).hex $(PROJECT).eep sizeafter $(PROJECT).lss## Compile
Is there a way to get avrdude to write its output to a log file?
Thanks for the changes. Unfortunatly they did not fix the problem. In the end I attached a logic analyser to the Xmega to monitor the serial port. I could see that your bootloader responded correctly but it still did not work. After looking at the Avrdude code I noticed that it did not seem to be expecting an echo of the command it sent. I commented out that line in the bootloader and it works./* Main loop */ for(;;) { val = recchar(); // Wait for command character. // sendchar(val);At this point in time it goes through the program procedure but gives errors for each byte. The chip is not being programmed. I am not familier with avrdude because I just use AS6 to program the chips, so I need to do some more testing.
One thing I have not mentioned is that my xmega is a 64a3u not a 64a3. When I try change that in the make file I get an error, so I have just left in on 64a3. I am not sure if there is any difference when it comes to self programming.
Is there a way to get avrdude to write its output to a log file?I tried 19200 and 9600 baud and got the same results.
Hmm... I'm pretty sure the value has to be echoed, but I could be wrong. It's been a long time since I wrote a lot of that code.
Does AVROSP2 work? It should work fine with the bootloader if I remember correctly and it implements the AVR911 protocol.
To add support for another MCU, you have to do two things:
1) Add two constants in the makefile as I explain in the README. You can find those values in the datasheet or in iox64a3u.h in this situation.
From iox64a3u.h:
#define BOOT_SECTION_START (0x10000) #define BOOT_SECTION_SIZE (4096) #define BOOT_SECTION_PAGE_SIZE (256) #define BOOT_SECTION_END (BOOT_SECTION_START + BOOT_SECTION_SIZE - 1)
Because the x64a3 is close, the version you made worked. For completeness in case anyone else finds this thread, the following makefile constants can be defined using the information in my quote directly above this paragraph:
ifeq ($(MCU), atxmega64a3u) BOOT_SECTION_START_IN_BYTES = 0x10000 FLASH_PAGE_SIZE = 256 endif
In Windows, I found that file here:
C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.2.1002\avr8-gnu-toolchain\avr\include\avr
2) You probably have to tell AVRDUDE that you're using x64a3u instead of x64a3. I recall having a problem with this when AVRDUDE was missing a lot of the Xmegas from avrdude.conf. I bet if you search in avrdude.conf, you'll see a bunch of xmega specific defines for each microcontroller. The section for x64a3u may or may not be missing, but, if it is, you'll need to add it. It should be somewhat obvious that you may run into problems if the -p argument doesn't actually have the correct value with respect to the hardware on the other end of the programmer:
You have this:
avrdude -c avr911 -P com10 -b19200 -p x64a3 -U flash:w:Timing1.hex
Instead of this:
avrdude -c avr911 -P com10 -b19200 -p x64a3u -U flash:w:Timing1.hex
I don't know for sure that it causes any issues since the two microcontrollers are very similar, but since you're having issues it's a good thing to try.
As I said above
One thing I have not mentioned is that my xmega is a 64a3u not a 64a3. When I try change that in the make file I get an error, so I have just left in on 64a3
Error 1 'PROGMEM_PAGE_SIZE' undeclared (first use in this function)
which I what I posted above.
I tried both with and without the 'u' for Avrdude and got the same result - I does not write to the chip. I then thought it might have something to do with not being able to specify the correct chip in the make file. I am now in the process of trying to convert the program to compile without using the makefile
I didn't realize avr-gcc doesn't support the xmega64a3u.
I just did this on a computer that previously had nothing related to Atmel, Winavr, etc. installed.
1) Install winavr - let it add c:\winavr-20100110\bin to your path
2) git clone the bootloader
3) make
I then changed the makefile as I explained above:
MCU = atxmega64a3u ... ifeq ($(MCU), atxmega64a3u) BOOT_SECTION_START_IN_BYTES = 0x10000 FLASH_PAGE_SIZE = 256 endif
And this is what it said:
$ make avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT eeprom_driver.o -c eeprom_driver.c unknown MCU 'atxmega64a3u' specifiedeeprom_driver.c:1: error: MCU 'atxmega64a3u' supported for assembler only
So, avr-gcc is the limiting case for the winavr approach. That sucks. Also, I checked and my guess was correct - avrdude 5.10, the version that comes with winavr, doesn't support the xmega64a3u. This version does, though.
I can't help you with your AS6 issues until you upload an example. I've never built the project in any of the IDEs and there's a lot that could be wrong.
What happens with Atmel Toolchain 3.4.2 (avr-gcc 4.7.2)? It's almost 4 years younger than WinAVR and is almost bound to have support for all the X-U chips.
Initially, it died after PROGMEM_PAGE_SIZE wasn't defined.
$ make avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT eeprom_driver.o -c eeprom_driver.c avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT Xmega_Bootloader.o -c Xmega_Bootloader.c Xmega_Bootloader.c: In function 'main': Xmega_Bootloader.c:122:64: error: 'PROGMEM_PAGE_SIZE' undeclared (first use in this function) Xmega_Bootloader.c:122:64: note: each undeclared identifier is reported only once for each function it appears in Xmega_Bootloader.c: In function 'BlockLoad': Xmega_Bootloader.c:402:30: error: 'PROGMEM_PAGE_SIZE' undeclared (first use in this function) Xmega_Bootloader.c:402:23: warning: unused variable 'buffer' [-Wunused-variable] makefile:124: recipe for target `Xmega_Bootloader.o' failed make: *** [Xmega_Bootloader.o] Error 1
I added this to Xmega_Bootloader.c temporarily:
#define PROGMEM_PAGE_SIZE 256
Output:
$ make avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT eeprom_driver.o -c eeprom_driver.c avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT Xmega_Bootloader.o -c Xmega_Bootloader.c avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT serial.o -c serial.c avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT sp_driver.o -x assembler-with-cpp -Wa,-gdwarf2 -c sp_driver.s avr-gcc -mmcu=atxmega64a3u -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3u -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT CCP_Write.o -x assembler-with-cpp -Wa,-gdwarf2 -c CCP_Write.s avr-gcc -mmcu=atxmega64a3u -Wl,-Map=Xmega_Bootloader.map -Wl,-section-start=.text=0x10000 eeprom_driver.o Xmega_Bootloader.o serial.o sp_driver.o CCP_Write.o -o Xmega_Bootloader.elf avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature Xmega_Bootloader.elf Xmega_Bootloader.hex avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Xmega_Bootloader.elf Xmega_Bootloader.eep || exit 0 Size after: Xmega_Bootloader.elf : section size addr .text 3136 65536 .BOOT 58 68672 .data 0 8396800 <------ New in Atmel toolchain .stab 1740 0 <------ New in Atmel toolchain .stabstr 151 0 <------ New in Atmel toolchain .comment 47 0 <------ New in Atmel toolchain .debug_aranges 176 0 .debug_info 4900 0 .debug_abbrev 1204 0 .debug_line 1990 0 .debug_frame 648 0 .debug_str 2157 0 .debug_loc 3086 0 .debug_ranges 56 0 Total 19349 avr-objdump -h -S Xmega_Bootloader.elf > Xmega_Bootloader.lss
The .data, .stab, .stabstr, and .comment lines in the size related output are new. I don't see them when using avr-gcc in Winavr (built for the xmega64a3 instead of the xmega64a3u). I don't know if it's a problem or not because the address doesn't immediatey make sense for .data (0x802000 or 8,396,800). According to iox64a3u.h, the data section should start at 0x0000 and the boot section should start at 0x10000 (65536).
Here's the Winavr output for reference:
$ make avr-gcc -mmcu=atxmega64a3 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3 -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT eeprom_driver.o -c eeprom_driver.c avr-gcc -mmcu=atxmega64a3 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3 -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT Xmega_Bootloader.o -c Xmega_Bootloader.c avr-gcc -mmcu=atxmega64a3 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3 -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT serial.o -c serial.c avr-gcc -mmcu=atxmega64a3 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3 -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT sp_driver.o -x assembler-with-cpp -Wa,-gdwarf2 -c sp_driver.s avr-gcc -mmcu=atxmega64a3 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -DFLASH_PAGE_SIZE=256 -DMCU=atxmega64a3 -DBAUD_RATE=115200 -DMY_UART=C,0 -DENTER_BOOTLOADER_PIN=B,2 -DLED_PIN=D,2 -DLED_ON=0 -DBOOTLOADER_PIN_EN=0 -DBOOTUP_DELAY= -MD -MP -MT CCP_Write.o -x assembler-with-cpp -Wa,-gdwarf2 -c CCP_Write.s avr-gcc -mmcu=atxmega64a3 -Wl,-Map=Xmega_Bootloader.map -Wl,-section-start=.text=0x10000 eeprom_driver.o Xmega_Bootloader.o serial.o sp_driver.o CCP_Write.o -o Xmega_Bootloader.elf avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature Xmega_Bootloader.elf Xmega_Bootloader.hex avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Xmega_Bootloader.elf Xmega_Bootloader.eep || exit 0 Size after: Xmega_Bootloader.elf : section size addr .text 2998 65536 .BOOT 58 68534 .debug_aranges 168 0 .debug_pubnames 353 0 .debug_info 3465 0 .debug_abbrev 1004 0 .debug_line 2694 0 .debug_frame 304 0 .debug_str 1776 0 .debug_loc 1754 0 .debug_ranges 32 0 Total 14606 avr-objdump -h -S Xmega_Bootloader.elf > Xmega_Bootloader.lss
Well, this makes sense. Just to confirm, I attached an image of the include files for each compiler. The one on the left is Winavr, which doesn't have a header file for the x64a3u. The one on the right is the Atmel toolchain include directory, which has an include file for the x64a3u.
Here's the fun part. The PROGMEM_PAGE_SIZE define is present in the include file for the x64a3, but not the x64a3u.
iox64a3.h:
... /* ========== Constants ========== */ #define PROGMEM_START (0x0000) #define PROGMEM_SIZE (69632) #define PROGMEM_PAGE_SIZE (256) #define PROGMEM_END (PROGMEM_START + PROGMEM_SIZE - 1) #define APP_SECTION_START (0x0000) #define APP_SECTION_SIZE (65536) #define APP_SECTION_PAGE_SIZE (256) #define APP_SECTION_END (APP_SECTION_START + APP_SECTION_SIZE - 1) ...
iox64a3u.h:
... /* ========== Constants ========== */ #define PROGMEM_START (0x0000) #define PROGMEM_SIZE (69632) #define PROGMEM_END (PROGMEM_START + PROGMEM_SIZE - 1) #define APP_SECTION_START (0x0000) #define APP_SECTION_SIZE (65536) #define APP_SECTION_PAGE_SIZE (256) #define APP_SECTION_END (APP_SECTION_START + APP_SECTION_SIZE - 1) ...
I filed a bug (I'm not sure if I put it in the right place): http://asf.atmel.com/bugzilla/sh...
This define is missing from a ton of io files in toolchain 3.4.2:
iox128a1u.h iox128a3u.h iox128a4u.h iox128b1.h iox128b3.h iox128c3.h iox128d4.h iox16a4u.h iox16c4.h iox16e5.h iox192a3u.h iox192c3.h iox256a3bu.h iox256a3u.h iox256c3.h iox32a4u.h iox32c3.h iox32c4.h iox32d3.h iox32e5.h iox384c3.h iox384d3.h iox64a1u.h iox64a3u.h iox64a4u.h iox64b1.h iox64b3.h iox64c3.h iox64d4.h iox8e5.h
I dont think it is a bug that PROGMEM_PAGE_SIZE is missing. I think its because they are making provision for different page sizes in different parts of flash:
#define APP_SECTION_PAGE_SIZE (256) #define APPTABLE_SECTION_PAGE_SIZE (256) #define BOOT_SECTION_PAGE_SIZE (256) #define USER_SIGNATURES_PAGE_SIZE (256) ....
So in the case of the bootloader, if I want to load a new application I will put it into the APP_SECTION.
Just to be clear, I am using A6 on windows.
I have got it to compile without the make file but just for my board by hardcoding things like baud rate, usart etc. The result using Avrdude is the same. It just gives errors when writing.
As already mentioned Avrdude is not happy the the commands are echoed back. I commeneted out the line:
// sendchar(val);
I can't help you with your AS6 issues until you upload an example. I've never built the project in any of the IDEs and there's a lot that could be wrong
Thanks for your help thus far. There is no point in uploading an example. Apart from commenting out the echo line the rest of the code is unchanged from what I downloaded from your site. I built it for the x64a3 using your make file in the Ide. This works and as far as I can tell the page locations and sizes should be the same on the x64a3u.
I have since built it without the make file and without some of your macros (just to keep things simple) and it compiles and runs exactly the same. Avrdude throws and error when trying to program:
avrdude: Version 6.0.1, compiled on Sep 18 2013 at 08:20:41
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "F:\AvrDude\avrdude.conf"
Using Port : com10
Using Programmer : avr109
Overriding Baud Rate : 19200
AVR Part : ATxmega64A3U
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 50 50 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 0 0 0x00 0x00
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 2048 32 0 0 0 0x00 0x00
application 0 0 0 0 no 65536 256 0 0 0 0x00 0x00
apptable 0 0 0 0 no 4096 256 0 0 0 0x00 0x00
boot 0 0 0 0 no 4096 256 0 0 0 0x00 0x00
flash 0 0 0 0 no 69632 256 0 0 0 0x00 0x00
usersig 0 0 0 0 no 256 256 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Programmer Type : butterfly
Description : Atmel AppNote AVR109 Boot Loader
Connecting to programmer: .
Found programmer: Id = "XmegaBl"; type = S
Software Version = 1.1; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=256 bytes.
Programmer supports the following devices:
Device code: 0xfa
avrdude: devcode selected: 0xfffffffa
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9642
avrdude: NOTE: Programmer supports page erase for Xmega devices.
Each page will be erased before programming it, but no chip erase is performed.
To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading input file "Timing1.hex"
avrdude: input file Timing1.hex auto detected as Intel Hex
avrdude: writing application (28226 bytes):
Writing | avrdude: butterfly_page_erase() called on memory type "application"
***failed;
***failed;
...
# | 100% 0.64s
avrdude: 28226 bytes of application written
avrdude: verifying application memory against Timing1.hex:
avrdude: load data application data from input file Timing1.hex:
avrdude: input file Timing1.hex auto detected as Intel Hex
avrdude: input file Timing1.hex contains 28226 bytes
avrdude: reading on-chip application data:
Reading | avr_read(): error reading address 0x0000
read operation not supported for memory "application"
avrdude: failed to read all of application memory, rc=-2
avrdude: butterfly_recv(): programmer is not responding
I used this command line:
avrdude -c avr109 -P com10 -b19200 -p x64a3u -v -l log.txt -U application:w:Timing1.hex
I am using an FT232 USB to serial converter. At this stage I think it is more of a problem of the way Avrdude handles this set up than the bootloader. Avrdude seems to close the conection after sending this:
SVvpabtTúPsLE
= hex
1b 53 56 76 70 61 62 74 54 fa 50 73 4c 45
I have checked the response from the bootloader and they all seem correct??
XmegaBl11?SYY
which is this in hex:
58 6d 65 67 61 42 6c 31 31 3f 53 59 59 01 00 fa 00 0d 0d 42 96 1e 0d
I Have made 'some' progress. Avrdude goes through the program cycle without errors until it disconnects, it then complains because the bootloader does not reply.
It apears to be programming but there is nothing in the flash. Here is a little eample of what it does:
73 s Answer: 2013/11/03 14:34:33.53764 (+0.0000 seconds) 42 96 1E B–. Request: 2013/11/03 14:34:33.53764 (+0.0000 seconds) 65 e Answer: 2013/11/03 14:34:33.55364 (+0.0156 seconds) 0D . Request: 2013/11/03 14:34:33.58464 (+0.0313 seconds) 41 00 00 A.. Answer: 2013/11/03 14:34:33.58464 (+0.0000 seconds) 0D . Request: 2013/11/03 14:34:33.69364 (+0.1094 seconds) 42 01 00 46 0C 94 A9 05 0C 94 C9 05 0C 94 C9 05 B..F.”©..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 90 06 .Ӄ..Ӄ..Ӄ..”Â. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 FB 2C 0C 94 BF 2D .Ӄ..Ӄ..”û,.”¿- 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 8D 2E .Ӄ..Ӄ..Ӄ..”Â. 0C 94 B7 2E 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .”·..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 .Ӄ. Answer: 2013/11/03 14:34:33.72464 (+0.0313 seconds) 0D . Request: 2013/11/03 14:34:33.72464 (+0.0000 seconds) 41 00 80 A.€ Answer: 2013/11/03 14:34:33.72464 (+0.0000 seconds) 0D . Request: 2013/11/03 14:34:33.81864 (+0.0938 seconds) 42 01 00 46 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 B..F.Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ.
I dont think it is a bug that PROGMEM_PAGE_SIZE is missing. I think its because they are making provision for different page sizes in different parts of flash:#define APP_SECTION_PAGE_SIZE (256) #define APPTABLE_SECTION_PAGE_SIZE (256) #define BOOT_SECTION_PAGE_SIZE (256) #define USER_SIGNATURES_PAGE_SIZE (256) ....So in the case of the bootloader, if I want to load a new application I will put it into the APP_SECTION.
I saw this as well, but I couldn't find an instance where the page sizes were different. I still think it's a bug because it breaks backward compatibility with no warning whatsoever.
Just to be clear, I am using A6 on windows.
I have got it to compile without the make file but just for my board by hardcoding things like baud rate, usart etc. The result using Avrdude is the same. It just gives errors when writing.
I understand, but I'm still confused why you went through the trouble of doing this with AS6. The latest Atmel toolchain works fine as I showed above with the makefile.
As already mentioned Avrdude is not happy the the commands are echoed back. I commeneted out the line:
// sendchar(val);
This is the first time I've heard of this issue and a lot of people are using my bootloader. I've never seen this issue on any of my own designs either. Something may have changed in AVRDUDE 6, so I'll remove that line I guess.
Thanks for your help thus far. There is no point in uploading an example. Apart from commenting out the echo line the rest of the code is unchanged from what I downloaded from your site. I built it for the x64a3 using your make file in the Ide. This works and as far as I can tell the page locations and sizes should be the same on the x64a3u.
I have since built it without the make file and without some of your macros (just to keep things simple) and it compiles and runs exactly the same. Avrdude throws and error when trying to program:
I'm not really sure what you mean because I don't think the makefile could possibly be more complicated than what you're doing. There's a handful of defines and that's it. The only thing I had to do to build for the x64a3u with the makefile was add a define for PROGMEM_PAGE_SIZE and then it worked as expected. I'll add a line in the README and an example in the makefile for parts that need defines because I'm assuming there will never be resolution in the toolchain.
As an aside, the whole point of this bootloader is to be easy because Atmel doesn't know how to provide easy to use code. AVRDUDE seems to be the issue, so how the project is built is almost completely decoupled from how it's programmed. From the information in this thread, it's not clear to me what you've gained by using AS6 instead of the standalone makefile approach. Put the Atmel toolchain in your path, add a define, and run make. What am I missing? It's obviously fine to want to use AS6, but it seems to be more difficult especially considering you needed to change the source code.
avrdude -c avr109 -P com10 -b19200 -p x64a3u -v -l log.txt -U application:w:Timing1.hex
I don't know if this matters, but I think you should be using -c avr911.
I Have made 'some' progress. Avrdude goes through the program cycle without errors until it disconnects, it then complains because the bootloader does not reply.
It apears to be programming but there is nothing in the flash. Here is a little eample of what it does:73 s Answer: 2013/11/03 14:34:33.53764 (+0.0000 seconds) 42 96 1E B–. Request: 2013/11/03 14:34:33.53764 (+0.0000 seconds) 65 e Answer: 2013/11/03 14:34:33.55364 (+0.0156 seconds) 0D . Request: 2013/11/03 14:34:33.58464 (+0.0313 seconds) 41 00 00 A.. Answer: 2013/11/03 14:34:33.58464 (+0.0000 seconds) 0D . Request: 2013/11/03 14:34:33.69364 (+0.1094 seconds) 42 01 00 46 0C 94 A9 05 0C 94 C9 05 0C 94 C9 05 B..F.”©..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 90 06 .Ӄ..Ӄ..Ӄ..”Â. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 FB 2C 0C 94 BF 2D .Ӄ..Ӄ..”û,.”¿- 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 8D 2E .Ӄ..Ӄ..Ӄ..”Â. 0C 94 B7 2E 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .”·..Ӄ..Ӄ..Ӄ. 0C 94 C9 05 .Ӄ. Answer: 2013/11/03 14:34:33.72464 (+0.0313 seconds) 0D . Request: 2013/11/03 14:34:33.72464 (+0.0000 seconds) 41 00 80 A.€ Answer: 2013/11/03 14:34:33.72464 (+0.0000 seconds) 0D . Request: 2013/11/03 14:34:33.81864 (+0.0938 seconds) 42 01 00 46 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 B..F.Ӄ..Ӄ..Ӄ. 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 0C 94 C9 05 .Ӄ..Ӄ..Ӄ..Ӄ.
I don't know if the protocol requires a response at this point because there's no documentation, which means either AVRDUDE or the bootloader are probably doing something wrong. It's easy for me to change the bootloader, but AVRDUDE seems to be a moving target.
Regardless, something else must be wrong because the lack of a response shouldn't be preventing it from programming.
I changed the project to support both new and old Xmega ioxxxx.h files. I tested it with both compilers (Winavr and Atmel 3.4.2). The changes are noted in the README file as well as the makefile. You should be able to build at the command line for the x64a3u.
Basically, this:
ifeq ($(MCU), atxmega64a3u)
BOOT_SECTION_START_IN_BYTES = 0x10000
FLASH_PAGE_SIZE = 256
endif
changed to this:
ifeq ($(MCU), atxmega64a3u) BOOT_SECTION_START_IN_BYTES = 0x10000 BOOT_PAGE_SIZE = 256 APP_PAGE_SIZE = 256 endif
PROGMEM_PAGE_SIZE is no longer used anywhere in the project.
I will try it from the command line. Thanks for all your help
I don't know if this matters, but I think you should be using -c avr911.
Ok I tried using your updated files. I had to change the make because windows make does not like sizebefore and sizeafter:
## Build all: $(TARGET) $(PROJECT).hex $(PROJECT).eep $(PROJECT).lss ##all: sizebefore $(TARGET) $(PROJECT).hex $(PROJECT).eep sizeafter $(PROJECT).lss
The only other change was I added baudrate of 19200.
I get exactly the same thing as before. Avrdude runs through and the bootloader replies with a 'cr' for each page but the chip remains blank.
Connecting to programmer: .
Found programmer: Id = "XmegaBl"; type = S
Software Version = 1.1; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=256 bytes.
Programmer supports the following devices:
Device code: 0xfa
avrdude: devcode selected: 0xfffffffa
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9642
avrdude: erasing chip
avrdude: reading input file "Timing1.hex"
avrdude: input file Timing1.hex auto detected as Intel Hex
avrdude: writing flash (28226 bytes):
Writing | ################################################## | 100% 15.52s
avrdude: 28226 bytes of flash written
avrdude: ser_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Ok I tried using your updated files. I had to change the make because windows make does not like sizebefore and sizeafter:## Build all: $(TARGET) $(PROJECT).hex $(PROJECT).eep $(PROJECT).lss ##all: sizebefore $(TARGET) $(PROJECT).hex $(PROJECT).eep sizeafter $(PROJECT).lssThe only other change was I added baudrate of 19200.
I get exactly the same thing as before. Avrdude runs through and the bootloader replies with a 'cr' for each page but the chip remains blank.Connecting to programmer: . Found programmer: Id = "XmegaBl"; type = S Software Version = 1.1; No Hardware Version given. Programmer supports auto addr increment. Programmer supports buffered memory access with buffersize=256 bytes. Programmer supports the following devices: Device code: 0xfa avrdude: devcode selected: 0xfffffffa avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e9642 avrdude: erasing chip avrdude: reading input file "Timing1.hex" avrdude: input file Timing1.hex auto detected as Intel Hex avrdude: writing flash (28226 bytes): Writing | ################################################## | 100% 15.52s avrdude: 28226 bytes of flash written avrdude: ser_recv(): programmer is not responding avrdude: butterfly_recv(): programmer is not responding
I'll try to dig in more tonight, but at least the bootloader is working with the makefile now. This is at least consistent with what you did before, but hopefully it was far easier than hacking the project to work in AS6, right?
Can you try writing a much smaller file? I mean something on the order of 50-100 bytes...
int main(void) {
while(1);
}
Two other questions:
1) Have you verified that Timing.hex works if you program it directly via PDI?
2) Are you sure the lock bits aren't set?
Timing.hex works if I program it via the PDI port using A6. All the lock bits are cleared - I have re-checked them.
To check if AVrdude worked or not I have each time dumped the contents of flash to a file via PDI. All the bytes are 0xff apart from the bootloader section.
I will try it with a smaller file as you suggest
I tried it with a simple test as you suggested and mostly the same result. I say most because during my testing it did program the chip first with the small hex file then with the larger one. Unfortunatly this only happens about once in every 10 of 15 program cycles. I have alaso tried with baud set to 9600 and 57.. no difference.
I tried it with a simple test as you suggested and mostly the same result. I say most because during my testing it did program the chip first with the small hex file then with the larger one. Unfortunatly this only happens about once in every 10 of 15 program cycles. I have alaso tried with baud set to 9600 and 57.. no difference.
This is definitely progress, though. To be clear, it did work, right? You verified that something made it into the program section?
I'll help you figure this out. We're close.
yes it worked. One time it was just simple while(1) and then on very next attempt it programmed my program which ran normally. After that I tried various things such as powering down and up etc. It worked once or twice but there did not seem to be any pattern to it. If I program the chip via sdi then try, it does erase the program but then does not program it. I even tried a slightly different sp_driver.S file from xboot but it was still the same. It looks like some subtle timing issue.
It's seems like a failed sentinel on a wait loop somewhere. I've had a similar problem in the past, but I can't remember what happened. I'll dig in when I get home from work.
I haven't been able to figure out what's wrong. I've been programming an xmega16a4 repeatedly for the last hour or so with no issues. I'm using AVRDUDE 5.10. I think that's the only difference since you're using the makefile approach now. I'll try building the newest AVRDUDE in the next day or so to see if I can replicate your issues.
I am going to try an older version of avrdude. According to the monitoring I did on the serial data your program seems to be giving all the right responses to the requests. I have been looking at the latest Avrdude buglist and found this:
http://savannah.nongnu.org/bugs/?func=detailitem&item_id=40112 It is what I first had when I started with this. I think its because of the command echo. I also came across an old bug which had exactly the same problem that I am having, although it was fixed. Do you have any way of monitoring the data on the serial port? Then we could compare a working one with one that is not and see if there is a difference
Do you have any way of monitoring the data on the serial port?
Edit: Here's an even simpler program that also worked just fine with the associated logifle. It sets the output of PORTD BIT3 low. On my board, that's an active low LED.
#includeint main(void) { PORTD.OUTCLR = PIN3_bm; PORTD.DIRSET = PIN3_bm; while(1); }
===========================================
Here's a link to a github repo with code that I was able to program to an x16d4. Check the root directory for a file called "logfile."
I generated that file with this command:
avrdude -p x16d4 -P com5 -b 115200 -c avr911 -U flash:w:xmegatest/Debug/xmegatest.hex -vvvv 2> logfile
There's an error at the end:
avrdude.exe: error: programmer did not respond to command: exit bootloader
However, it worked anyway. Two LEDs on my custom board are blinking in sinusoidal patterns, which is exactly what's supposed to happen:
//TCD0 overflow interrupt. Timer frequency / Timer period = overflows per second.
ISR(TCD0_OVF_vect)
{
static uint16_t i;
//Generate a scaled sine wave value. This is crazy slow, but it works.
//The value will be between 0 and 255 and centered at 127.5.
uint16_t x = (uint16_t)(sin(2*M_PI*i/sine_frequency)*243.5+243.5);
TCD0.CCCBUF = x;
TCD0.CCDBUF = 488-x;
i++;
}
For reference:
avrdude.exe: Version 5.10, compiled on Jan 19 2010 at 10:45:23
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"
I tried it with version 5.11 of Avrdude and ver 6.
I see that you used ver 5.10 and it suports ATXMEGA16D4 but ver 5.11 does not.
Apart from my hex file being a little bigger everything else in 5.10 and 5.11 looked the same. Ver 6 does not have this:
avrdude.exe: Device signature = 0x1e9442
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: Send: A [41] . [03] . [fc]
avrdude.exe: Recv: . [0d]
avrdude.exe: Send: g [67] . [00] . [01] E [45]
avrdude.exe: Recv: . [ff]
avrdude.exe: Send: A [41] . [03] . [fd]
avrdude.exe: Recv: . [0d]
avrdude.exe: Send: g [67] . [00] . [01] E [45]
avrdude.exe: Recv: . [ff]
avrdude.exe: Send: A [41] . [03] . [fe]
avrdude.exe: Recv: . [0d]
avrdude.exe: Send: g [67] . [00] . [01] E [45]
avrdude.exe: Recv: . [ff]
avrdude.exe: Send: A [41] . [03] . [ff]
avrdude.exe: Recv: . [0d]
avrdude.exe: Send: g [67] . [00] . [01] E [45]
avrdude.exe: Recv: . [ff]
avrdude.exe: erasing chip
avrdude.exe: Send: e [65]
avrdude.exe: Recv: . [0d]
avrdude.exe: reading input file "xmegatest/Debug/xmegatest.hex"
avrdude.exe: input file xmegatest/Debug/xmegatest.hex auto detected as Intel Hex
avrdude.exe: writing flash (3916 bytes):
Writing | avrdude.exe: Send: A [41] . [00] . [00]
it just does:
avrdude: Device signature = 0x1e9642 avrdude: erasing chip avrdude: Send: e [65] avrdude: Recv: . [0d] avrdude: reading input file "xmegatest.hex" avrdude: input file xmegatest.hex auto detected as Intel Hex avrdude: writing flash (3936 bytes): Writing | avrdude: Send: A [41] . [00] . [00] avrdude: Recv: . [0d] avrdude: Send: B [42] . [01] . [00] F [46] . [0c] . [
I am wodering if it has something to do with the sp_driver.
I found this https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1111789#1111789 and he claims to have got it working by writing his own flash driver. I tried his code but dont know much AVR assembly and ran into a problem. He gives a small utility .s file but it is not for GCC. He did not provide a header. I tried. This is the assembly"
.section .text .global LoadZ LoadZ: movw Z, r16 ; Load R17:R16 into Z. ret .section .text .global LoadR0 LoadR0: movw r0, r16 ; Load R17:R16 into R1:R0. ret .section .text .global ReadELPM ReadELPM: elpm r16, Z ret
and I gave it this header
void LoadZ( unsigned int addr); void LoadR0(unsigned int addr); uint8_t _ReadELPM(uint8_t);
but the compiler gives an error for the
_LoadZ::
- it says it expected a constant and I have not figured that out yet.
Can you try with 5.10? We really need to try with the exact same software all the way around to see if something else is wrong.
AVRDUDE 5.10 doesn't support x16d4. I modified avrdude.conf to add support. All you have to do is copy the entry for x16a4 and modify the top few lines as follows:
#------------------------------------------------------------ # ATXMEGA16D4 #------------------------------------------------------------ part id = "x16d4"; desc = "ATXMEGA16D4"; signature = 0x1e 0x94 0x42; has_jtag = no; has_pdi = yes; nvm_base = 0x01c0;
If you want to add support for any MCU, make the necessary modifications in avrdude.conf and that's it.
I suppose sp_driver.s could be an issue. I don't have any xmegas with 64 kB or greater flash to try. That could be one of the issues.
I need to fix the error that pops up whenever the bootloader tries to exit. Maybe I'll stumble onto something that will fix your issue at the same time, but probably not. Can you get your hands on a smaller xmega to try? Also, I'm open to trying one of your boards if you want to send me one.
Also, I'm open to trying one of your boards if you want to send me one.
# MCU = atxmega128a1 # MCU = atxmega64a3 MCU = atxmega64a3u # MCU = atxmega32a4 # MCU = atxmega16a4 # MCU = atxmega16d4 # Choose a baud rate for the UART. # If you need a baud rate that is not listed in this makefile, you must add # new configuration statements in config.macros.h. Remember, Xmegas start-up # with a 2MHz clock. # BAUD_RATE = 9600 # BAUD_RATE = 19200 # BAUD_RATE = 38400 # BAUD_RATE = 57600 BAUD_RATE = 115200 # Specify a pin to check for entry into the bootloader. The notation is # PORT,PIN. For example, if you wanted to use PIN 3 on PORTC, you would set # the option as C,3. Then specifiy the logic value required to enable the # bootloader code (1 = enable the bootloader if the pin is VCC, 0 = enable # the bootloader if the pin is GND). BOOTLOADER_PIN = A,7 BOOTLOADER_PIN_ON = 0 # Specify a pin to control an LED. The notation is PORT,PIN. For example, if # you wanted to use PIN 6 on PORTA, you would set the option as A,6. Then # specifiy the logic value required to enable the LED (1 = output VCC to turn # on the LED, 0 = output GND to turn on the LED). LED_PIN = B,5 LED_ON = 1 # Specify which UART to use with PORT,NUM notation. For example, UART1 on # PORTD would be D,1. UART = E,0
One thing I did pick up is the following in your config_macros.h
// SPM control #define APP_END(APP_SECTION_START + APP_SECTION_SIZE) #if(APP_SECTION_SIZE >= 0x10000) #define LARGE_MEMORY #endif
I think it should be
#if(APP_SECTION_SIZE > 0x10000)
because the size is 0x10000 - 1 because it starts at zero. I did try that and then it hangs when it gets to the 'e' chip erase. That sp call does not seem to be happy with an uint16 and wants an uint32
Comparing to 0x10000 is correct. 0xFFFF is 65535, which is 65536 addresses. Big memory starts when the number of addresses is 65537, which is 0x10001 when it's zero based.
I spent the last 30 minutes trying to build AVRDUDE 6.0.1, but I can't spend any more time on that. What a piece of crap with no documentation. I remember having problems with this a long time ago as well. Error after error with no help on the website at all regarding the list of required dependencies. The onion peeling process brought me to this:
/bin/bash ./ylwrap lexer.l .c lexer.c -- : gcc -DHAVE_CONFIG_H -I. -DCONFIG_DIR=\"/usr/local/etc\" -Wall -Wno-pointer-sign -g -O2 -MT libavrdude_a-lexer.o -MD -MP -MF .deps/libavrdude_a-lexer.Tpo -c -o libavrdude_a-lexer.o `test -f 'lexer.c' || echo './'`lexer.c gcc: error: ./lexer.c: No such file or directory gcc: fatal error: no input files compilation terminated. make[2]: *** [libavrdude_a-lexer.o] Error 4 make[2]: Leaving directory `/home/anthony/Downloads/avrdude-6.0.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/anthony/Downloads/avrdude-6.0.1' make: *** [all] Error 2
If you can try AVRDUDE 5.10, that would be helpful. There's a prebuilt windows binary.
Program your xmega via PDI and make sure it actually writes the memory. Then erase the program memory with the bootloader and make sure it actually erased. Please report the results of that.
I updated the bootloader to fix the error that's generated when AVRDUDE sends 'E' (exit bootloader). The serial.c function that sends data is only checking to see if data buffer is empty, not if the data has finished sending. That's what we want most of the time, but the character needs to finish transmitting before the bootloader exits and kills the UART clock.
else if(val=='E')
{
// Clear the transmit complete flag
Uart(MY_UART).STATUS =
(1 << USART_TXCIF_bp);
sendchar('\r');
while (!(Uart(MY_UART).STATUS &
(1 << USART_TXCIF_bp)));
SP_WaitForSPM();
CCP_RST();
}
Comparing to 0x10000 is correct. 0xFFFF is 65535, which is 65536 addresses. Big memory starts when the number of addresses is 65537, which is 0x10001 when it's zero based.
#define APP_SECTION_SIZE (65536)
which = 0x10000 . It only needs 16 bits to address.
Remember I converted your bootloader to run in the IDE without makefile? Well I ran it in debug mode and came across a problem. It looks like when the eeprom is erased a flag is not reset to indicate that the bufferpage is empty. I commented the eeprom erase lines out and it works. I then tried the same with your makefile version of the code but it does not. I am currently sitting comparing the two projects hoping to find out what is different between them
Can you use my make file settings and build the bootloader on your linux platform? Then give me the hex file to try. Perhaps there is something odd about the way windows is doing the build with a makefile?
Can you use my make file settings and build the bootloader on your linux platform? Then give me the hex file to try. Perhaps there is something odd about the way windows is doing the build with a makefile?
I can't build on Linux. I tried to build AVRDUDE, but the amount of errors is ridiculous. I can't waste more time making that work. You need to try AVRDUDE 5.10 in Windows. Many people have used it with no issues in Windows, so that's not the problem.
Quote:
Comparing to 0x10000 is correct. 0xFFFF is 65535, which is 65536 addresses. Big memory starts when the number of addresses is 65537, which is 0x10001 when it's zero based.
That is is why it should be > and not >= . The 64a3 has an address range of 0 - 0xffff which is 'small memeory' The number of bytes = 0xffff + 1 which is 0x10000. the iox files says
#define APP_SECTION_SIZE (65536)which = 0x10000 . It only needs 16 bits to address.
I didn't see that you posted two snippets of code earlier. I didn't write that code and I didn't change any of it either. Maybe it's a bug, but it doesn't seem to matter. All it does is change an int to a long. You didn't say whether or not this made a difference in your situation.
Remember I converted your bootloader to run in the IDE without makefile? Well I ran it in debug mode and came across a problem. It looks like when the eeprom is erased a flag is not reset to indicate that the bufferpage is empty. I commented the eeprom erase lines out and it works. I then tried the same with your makefile version of the code but it does not. I am currently sitting comparing the two projects hoping to find out what is different between them
I didn't write any of the eeprom code. I don't know which flag you are talking about.
I can't build on Linux. I tried to build AVRDUDE, but the amount of errors is ridiculous.
with no help on the website at all regarding the list of required dependencies
I can't build on Linux
I didn't write that code and I didn't change any of it either. Maybe it's a bug, but it doesn't seem to matter.
I didn't write any of the eeprom code. I don't know which flag you are talking about.
Quote:
with no help on the website at all regarding the list of required dependencies
You mean it doesn't use an autoconf "configure"?
Sure, but it doesn't list everything. The website has zero helpful information and the output of configure didn't mention many of the dependencies. Open source software is somewhat worthless if people don't make a webpage that says "here's how you build it" especially when they require uncommon packages. Forget trying to build AVRDUDE on Windows - that's far worse. One of these days, I'm going to rewrite AVRDUDE in python so it's actually portable.
I'll try a binary of 6.0.1 when I get home. Thanks for that tip - I forgot those were available. I really don't like needing to rely on binaries that someone else had to build, but that's the situation right now so I'll get over it.
Sorry I thought your make files were from a linux system because they contain sizebefore and sizeafter which does not seem to work on windows. Ok then just build it on whatever you use :)
I am aware that you did not write it.
I know you did not write it. I was simply telling you what I found because I though that you would be interested.
I also understand that it works. If you read here on freaks there seem to be two groups of people... those who have working bootloaders and those that dont. As I said at the start, I have a working bootloader from Chip45. The problem is that it has no source. That is how I know that bootloaders do work on the xmega64a3u. The problem is that the ones that do have source either dont work on the 64a3u or dont build on windows - or let me re-state, I with my limited er non existent knowledge of make on windows have been unable to get it to build
You seem to have missed above where I said that I got it working on the one that I built in A6 without using the makefile, that is why I thought it would be interesting to see if you use my makfile settings which I posted above to compile it in your invironment and then let me test the hex file on my board.
You seem to have missed above where I said that I got it working on the one that I built in A6 without using the makefile, that is why I thought it would be interesting to see if you use my makfile settings which I posted above to compile it in your invironment and then let me test the hex file on my board.
I saw it, but those settings won't cause any issues either way. If you got the bootloader to work using AS6, it must be an issue with your compiler. Are you using nmake in powershell or vs shell?
A better test would be for you to download and install cygwin + winavr and atmel toolchain 3.4.2. If you get it to work using that combination of software, then the problem is likely whatever you're currently doing outside of AS6. If you have a few minutes tonight, we can do that together.
Also, upload your AS6 project that works please. That will be very helpful.
I do appreciate your persistance and help. Thanks a lot
I do appreciate your persistance and help. Thanks a lot
No problem. I really hope we figure out a solution. Thanks for your contributions. I think you've helped fix a few errors and inconsistencies.
Are you using nmake in powershell or vs shell?
C:\Program Files\Atmel\Atmel Studio 6.0\make\make.exe
GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc.
The thing is that I am happy compiling without make. I do my debugging in A6 and also programming of devices. I am just trying to get it to work with make so that other people dont have to go through the same thing. That is why I thought that if you build the hex file on a system that you know works for other varients of AVR then it will be a good test to see if it it works in the 64a3U
Quote:
Are you using nmake in powershell or vs shell?
I use winxp ->Run->cmd I then used make that came with the version of GCC that comes with A6C:\Program Files\Atmel\Atmel Studio 6.0\make\make.exeGNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc.The thing is that I am happy compiling without make. I do my debugging in A6 and also programming of devices. I am just trying to get it to work with make so that other people dont have to go through the same thing. That is why I thought that if you build the hex file on a system that you know works for other varients of AVR then it will be a good test to see if it it works in the 64a3U
I see. I'll do that when I get home and we'll see what happens. I'm fairly confident that the problem isn't with the bootloader. It seems to be related to the way you're building/compiling, but I don't know for sure.
A very strange thing happened. I rebooted my PC and then made the change to the code for when avrdude ends programming that you posted above. After that my code also did not work anymore. After doing some debugging I have finaly figured out what the actual problem is. It has to do with the way I operated my board.
How I operated my board.. For testing I deleted my program so the memory was just full of 0xff = NOP. Now when reset, if I did not hold the button down then the code would enter the boot loader and exit , then run through all the nops of missing code and back into the bootloader until I pressed the button. But what this does is it locks the Flash and prevents further programing until a reset happens. This bit of code which is the else part of the if statement which checks if the button is pressed:
else
{
SP_WaitForSPM();
SP_LockSPM();
EIND = 0x00;
funcptr(); // Jump to Reset vector 0x0000 in Application Section.
}
notice the
SP_LockSPM();
statement. I had seen this but assumed that the SPM was unlocked by some code in the sp_driver. I just read this in the data sheet:
Bit 0 – SPMLOCK: SPM Locked
This bit can be written to prevent all further self-programming. The bit is cleared at reset, and cannot be cleared from
software.
This is an easy mistake to make if the chip is blank because you can enter the bootloader at any time as I did. We should change the code so that if the spm lock is enabled it will force a reset. This will happen so quickly that you will still be pressing the button after restart and will enter the bootloader correctly
Add this to reset if SPM locked:
if(NVM.CTRLB & NVM_SPMLOCK_bm)
{
CCP_RST();
}
It will be after the if statement that checks if the pin is enabled to enter the bootloader and just above:
/* Initialization */ ADDR_T address = 0; unsigned int temp_int = 0; unsigned char val = 0;
A very strange thing happened. I rebooted my PC and then made the change to the code for when avrdude ends programming that you posted above. After that my code also did not work anymore. After doing some debugging I have finaly figured out what the actual problem is. It has to do with the way I operated my board.
How I operated my board.. For testing I deleted my program so the memory was just full of 0xff = NOP. Now when reset, if I did not hold the button down then the code would enter the boot loader and exit , then run through all the nops of missing code and back into the bootloader until I pressed the button. But what this does is it locks the Flash and prevents further programing until a reset happens. This bit of code which is the else part of the if statement which checks if the button is pressed:else { SP_WaitForSPM(); SP_LockSPM(); EIND = 0x00; funcptr(); // Jump to Reset vector 0x0000 in Application Section. }notice the
SP_LockSPM();statement. I had seen this but assumed that the SPM was unlocked by some code in the sp_driver. I just read this in the data sheet:
Quote:Bit 0 – SPMLOCK: SPM Locked
This bit can be written to prevent all further self-programming. The bit is cleared at reset, and cannot be cleared from
software.
I am not sure why my code worked multiple times earlier because I was operating it in the same way. In fact when I compared the code built with make and the code built without make multiple times I did each the same way. I have re-tested the eeprom issue and that does not seem to have an effect although it did earlier. :roll:This is an easy mistake to make if the chip is blank because you can enter the bootloader at any time as I did. We should change the code so that if the spm lock is enabled it will force a reset. This will happen so quickly that you will still be pressing the button after restart and will enter the bootloader correctly
Hmm.. I changed that function several times in the past, but I can't remember why I settled on what's currently committed. When the bootloader exits, this is the code that runs:
else if(val=='E') {
// Clear the transmit complete flag
Uart(MY_UART).STATUS = (1 << USART_TXCIF_bp);
sendchar('\r');
while (!(Uart(MY_UART).STATUS & (1 << USART_TXCIF_bp)));
SP_WaitForSPM();
CCP_RST();
}
I wrote CCP_RST(), which is an assembly function that does a literal reset of the board to make sure peripherals aren't initialized accidentally or unintentionally. That requires the bootloader entry condition to be cleared because the bootloader will enter again very quickly and then you'll have to force an exit condition with a programmer. With that said, I could change the last few lines to execute CCP_RST() and that will unlock the SPM bit. I could also add a check for the SPM bit at the beginning of the loop that did check the bootloader entry pin and then successfully entered the main bootloader loop.
I'm glad you got it working.
Add this to reset if SPM locked:
if(NVM.CTRLB & NVM_SPMLOCK_bm)
{
CCP_RST();
}
It will be after the if statement that checks if the pin is enabled to enter the bootloader and just above:
/* Initialization */ ADDR_T address = 0; unsigned int temp_int = 0;
You do want to make sure that it is locked after exit. That was the problem of the other bootloader I used. I dont think it was locked so sometimes on start up your main app would get a page deleted.
Just another thing regarding this problem. When I was testing, if it did not program the chip I did not reset, I just pressed the button and it went back into the bootloader. I did not know it was locked lol
I use this to reset
CCPWrite( &RST.CTRL, RST_SWRST_bm );//do a reset
But you do need the CCPWrite code which is also used for other things such as clock configuring
I use this to reset
CCPWrite( &RST.CTRL, RST_SWRST_bm );//do a resetBut you do need the CCPWrite code which is also used for other things such as clock configuring
CCP_RST does the same thing after writing the unlock code.
I updated the code. The first commit is the lock bit fix. The second commit is for readability. The main .c file is much cleaner now and I also added defines for the commands.