AVR911 xml files for xmega

Go To Last Post
62 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd be hugely surprised if avrdude did not support that protocol.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
Is there a way to get avrdude to write its output to a log file?
- The new option -l logfile allows to redirect diagnostic messages
to a logfile rather than stderr. Useful to record debugging
traces, in particular in environments which do not offer
shell-style redirection functionality for standard streams.
AVR Downloader/UploaDEr - News: AVRDUDE 6.0 released

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said above

Quote:
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 had made the change that your comments suggest in the make file, you can see them above in the makefile part I posted but then I get this error:
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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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' specified



eeprom_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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
Last Edited: Sun. Nov 3, 2013 - 02:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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);

Quote:

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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   .Ӄ..Ӄ..Ӄ..Ӄ.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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.

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

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

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

Last Edited: Sun. Nov 3, 2013 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Commit details

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will try it from the command line. Thanks for all your help

Quote:

I don't know if this matters, but I think you should be using -c avr911.

According to the Avrdude docs 109 and 911 equate to exactly the same thing. I tried both and just happen to paste the 109 entry here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Do you have any way of monitoring the data on the serial port?

Can't you get this anyway by adding "-v -v -v -v" to the avrdude command?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

#include 
int 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"
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 http://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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Also, I'm open to trying one of your boards if you want to send me one.

At the moment I dont have any extra boards but perhaps you could built the loader on your linux machine and then I could try the resulting hex file? Here are my seetings:

# 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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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();
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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.

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bandtank wrote:
I can't build on Linux. I tried to build AVRDUDE, but the amount of errors is ridiculous.
Which Linux distribution?
AVRDUDE 6 has been packaged on at least several Linux distributions.
Debian, Jessie, AVRDUDE

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

with no help on the website at all regarding the list of required dependencies

You mean it doesn't use an autoconf "configure"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I can't build on Linux

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 :)
Quote:

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 am aware that you did not write it.

Quote:

I didn't write any of the eeprom code. I don't know which flag you are talking about.

I know you did not write it. I was simply telling you what I found because I thought 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 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

Last Edited: Thu. Nov 7, 2013 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davidgrm wrote:
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've done that a few times now and the resulting hex files must not have worked for you. I have no problem with sizebefore and sizeafter in windows. I installed a minimal version of Cygwin in about 5 minutes for this task specifically. Maybe this is something we can discuss.

Quote:
I am aware that you did not write it.

I didn't mean that to sound snippy. It was purely meant to be informative. I don't have a lot of insight into some of the code because I modified specific pieces.

Quote:
I know you did not write it. I was simply telling you what I found because I though that you would be interested.

Same as above. I understand and appreciate your will to share. My main point has been to try to solve your problem, so I wanted to inform you that I had limited knowledge of the code you were discussing.

Quote:
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

I wish there was a way I could get my hands on one of your boards. Then I could definitely help you figure it out. I guess it all depends on how much you really need this. If you can get by with your currently working solution even though it's not ideal, that may be the way you have to go if we can't figure this out. Otherwise, if this is very important, then see if there's anything you can do to get a piece of hardware to me. I'll obviously send it back, but I'm almost out of ideas so there's not a lot of other options. I do want to help you figure this out. I've put a lot of effort in so far and I'd like to finish strong with a working solution for you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Pages