xboot + avrdude problems

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm testing this configuration on my old xmega32a4 while wating for new PCB for xmega64d4.

I'm able to program the bootloader and the application using srec_cat, jtagice3 and AS6.1. The application works fine.

But I can't get avrdude to program via UART. I have a FTDI (UB232R) converter connected from USB to GND and pins 12/13 (C0 RX/TX). It communicates fine with my application using a terminal program (Tera Term).

The first problem is that avrdude can't initialize the communication when also the appliction is loaded.

avrdude -v -v -p atxmega32a4 -P com22 -c avr109 -b 9600 -U flash:w:test.hex

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"

             Using Port                    : com22
             Using Programmer              : avr109
             avr910_devcode (avrdude.conf) : none
             Overriding Baud Rate          : 9600

It just stops there and looking with an oscilloscope it doesn't send a bit through UART. Isn't it supposed to send 0x1b? Why it stops there?

If I first put some ESC to the terminal, my application will reset and then the xboot will catch and wait. Then applying the same avrdude command:

avrdude -v -v -p atxmega32a4 -P com22 -c avr109 -b 9600 -U flash:w:test.hex

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"

             Using Port                    : com22
             Using Programmer              : avr109
             avr910_devcode (avrdude.conf) : none
             Overriding Baud Rate          : 9600
             AVR Part                      : ATXMEGA32A4
             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
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom         0     0     0    0 no       1024   32      0     0     0 0x00 0x00
               application    0     0     0    0 no      32768  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      36864  256      0     0     0 0x00 0x00
               prodsig        0     0     0    0 no        512  256      0     0     0 0x00 0x00
               usersig        0     0     0    0 no        512  256      0     0     0 0x00 0x00
               signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
               fuse0          0     0     0    0 no          1    0      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

             Programmer Type : avr910
             Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
    Software Version = 1.7; 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: 0x7b

avrdude.exe: devcode selected: 0x7b
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x1e9541
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "test.hex"
avrdude.exe: input file test.hex auto detected as Intel Hex
avrdude.exe: writing flash (100 bytes):

Writing | ################################################## | 100% 0.15s


avrdude.exe: 100 bytes of flash written
avrdude.exe: verifying flash memory against test.hex:
avrdude.exe: load data flash data from input file test.hex:
avrdude.exe: input file test.hex auto detected as Intel Hex
avrdude.exe: input file test.hex contains 100 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.14s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x00 != 0x1a
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

So no errors in erasing and writing, but verification fails and actually nothing happens (the old application is still there!).

If I try to reprogram the same application that has already been written in AS6.1, even the verification passes.

Thus avrdude seems to be able to read the flash, but not to erase nor write.

Trying with a newer version of avrdude (Version 6.0.1, compiled on Sep 18 2013 at 08:20:41) works just the same except I get a lot of "***failed;" during the writing part.

The fuses are:

USERID = 0xFF
WDWP = 8CLK
WDP = 8CLK
DVSDON = [ ]
BOOTRST = BOOTLDR
BODPD = DISABLED
RSTDISBL = [ ]
SUT = 0MS
WDLOCK = [ ]
BODACT = DISABLED
EESAVE = [X]
BODLVL = 1V6

FUSEBYTE0 = 0xFF (valid)
FUSEBYTE1 = 0x00 (valid)
FUSEBYTE2 = 0xBF (valid)
FUSEBYTE4 = 0xFF (valid)
FUSEBYTE5 = 0xF7 (valid)

I started with 115200 baud rate, but changed to 9600, since my application is using that. I edited this new option to xboot.h The same problems where also with 115200.

With just the bootloader (xboot-boot.hex) in flash avrdude doesn't stop, but the same problem with writing continues.

When avrdude doesn't stop (that is just a boatloader in flash or bootloader caught with couple of ESC from terminal) it does start the communication with 0x1b (ESC). What makes it not to send it in when it stops? Is it the incoming transmission from my application (a few bytes/s ascii)? Or how would avrdude know the difference? The bootloader doesn't transmit enything when caught with ESC.

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

Use "-v -v -v -v" instead of just two. That way avrdude will report all bytes sent and received.

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

Thanks, I didn't know that. Without sending the ESC's via terminal it shows just the same. When it doesn't stop it procudes the attached output for test.hex, which is not an application, just a small test file. It works just the same with the actual application.

Thus it seems to do some communication and gets the correct ID, but fails to write.

I tried to disconnect the TX (sending out from xmega) and that made avrdude go further, but obviously it failed, since there was no reply. So sending data to UART does stop avrdude. Is there a switch to override that?

If it matters, I run avrdude from cygwin xterm using bash shell.

Attachment(s): 

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

I have the same problem.

After successfully compiling xboot for my xmegaB1, programming fuses, and uploading the bootloader via jtagIce mk2, avrdude doesn't establish a serial connection.

Please do update us!

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

If y'all have JTAG's then surely you can look at what's happening inside the AVR and why things aren't going as planned?

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

The stopping of avrdude is related to opening the programmer, which first opens the port (serial port in my case) and then drains it. The draining function ser_drain contains a loop, which loops forever, if new data is received within ReadFiles timeout, which is 250 ms.

Why not first send 0x1b and then drain? This would support the xboot readme idea of catching 0x1b in the application for resetin to bootloader.

Actually butterfly.c does just that, but it drains after opening as well, which hangs it in my case. Open -> drain -> send 0x1b -> drain -> send "S" -> read. What is the use of the first drain?

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

Now I'm really confused!

I found out that thee "***failed" came from avr_write_byte returning non zero. With avr109 this function is butterfly_write_byte, which has:

        else {						/* write to flash */
      /* @@@ not yet implemented */
      cmd[2] = 2;
      size = 6;
      return -1;
    }

This is true for both avrdude version: 5.10 (WinAVR) and 6.0.1. Thus I guess it is never going to be implemented. Why doesnt't avrdude say it's not implemented, just some strange ***failed?

Writing to eeprom works like a charm, thus there is nothing wrong in xboot. avrdude is just not cabable of avr109 flash writing.

So how has the xboot readme been able to use????

avrdude -p atxmega64a3 -P com1 -c avr109 -b 115200 -U flash:w:main.hex

Did they have a specially patched avrdude?

Is there another AVR109 tool, which can be used from Linux command line?

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

Quote:
Did they have a specially patched avrdude?

That'd be my bet. What does the author say?

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

Now I got it working! Avrdude needed option -e. Then it didn't show any ***failed (didn't use anymore write_byte???) and programmed just fine.

I also changed some parameters in xboot, which may have helped, but it still fails without -e. Attached is the current xboot conf.

# Entry
USE_ENTER_DELAY = yes
USE_ENTER_PIN = no
USE_ENTER_UART = yes
USE_ENTER_I2C = no
USE_ENTER_FIFO = no

# Exit
LOCK_SPM_ON_EXIT = no

# Communication
USE_LED = yes
USE_UART = yes
USE_UART_EN_PIN = no
USE_I2C = no
USE_I2C_ADDRESS_NEGOTIATION = no
USE_ATTACH_LED = no
USE_FIFO = no

# General Options
USE_INTERRUPTS = no
USE_WATCHDOG = no

# Bootloader Features
ENABLE_BLOCK_SUPPORT = yes
ENABLE_FLASH_BYTE_SUPPORT = no
ENABLE_EEPROM_BYTE_SUPPORT = yes
ENABLE_LOCK_BITS = yes
ENABLE_FUSE_BITS = yes
ENABLE_FLASH_ERASE_WRITE = yes
ENABLE_CRC_SUPPORT = yes

# API
#ENABLE_API = yes
USE_API_VERSION = 1
ENABLE_API_LOW_LEVEL_FLASH = yes
ENABLE_API_SPM_WRAPPER = yes
ENABLE_API_FIRMWARE_UPDATE = yes

# Code Protection
ENABLE_CODE_PROTECTION = no
ENABLE_EEPROM_PROTECTION = no
ENABLE_BOOTLOADER_PROTECTION = no

# ENTER_PIN
ENTER_PORT_NAME       = C
ENTER_PIN             = 0
ENTER_PIN_STATE       = 0
ENTER_PIN_PUEN        = 1

# ENTER_DELAY
ENTER_BLINK_COUNT     = 10
ENTER_BLINK_WAIT      = 30000

# ENTER_UART
ENTER_UART_NEED_SYNC = yes

# ENTER_FIFO
#ENTER_FIFO_NEED_SYNC = yes

# USE_WATCHDOG
# Select only one
#WATCHDOG_TIMEOUT      = WDT_PER_8CLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_16CLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_32CLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_64CLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_128CLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_256CLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_512CLK_gc
WATCHDOG_TIMEOUT      = WDT_PER_1KCLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_2KCLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_4KCLK_gc
#WATCHDOG_TIMEOUT      = WDT_PER_8KCLK_gc

# LED
LED_PORT_NAME         = A
LED_PIN               = 0
LED_INV               = 1

# UART
# Select BAUD rate, port name, and UART number
UART_BAUD_RATE        = 9600
UART_PORT_NAME        = C
UART_NUMBER           = 0
UART_RX_PUEN          = yes

# UART RS485 Enable Output
#UART_EN_PORT_NAME     = C
#UART_EN_PIN           = 4
#UART_EN_PIN_INV       = 0

# FIFO
FIFO_DATA_PORT_NAME   = C
FIFO_CTL_PORT_NAME    = D
FIFO_RXF_N            = 3
FIFO_TXE_N            = 2
FIFO_RD_N             = 1
FIFO_WR_N             = 0
FIFO_BIT_REVERSE      = yes

# I2C
I2C_DEVICE_PORT       = C

I2C_MATCH_ANY         = 1
I2C_ADDRESS           = 0x10
I2C_GC_ENABLE         = 1

# I2C Address Autonegotiation
# Note: only works on XMega chips for the time being
# There is no easy way to get this to work on regular
# ATMega chips as they have no unique part ID number
I2C_AUTONEG_DIS_PROMISC       = 1
I2C_AUTONEG_DIS_GC            = 0
I2C_AUTONEG_PORT_NAME         = A
I2C_AUTONEG_PIN               = 2

# Attach LED
ATTACH_LED_PORT_NAME          = A
ATTACH_LED_PIN                = 1
ATTACH_LED_INV                = 1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I was able to program my xmega too.

My problem: I had the TX and RX serial points crossed!

I had forgotten that proper serial communication needs the following configuration: avr_TX -> FTDI_RX (Not avr_TX -> FTDI_TX).

I'm sure your '-e' command line option helps. I mean, the chip needs to be erased before programmed.

My problem now: once I program my xmega, the entire flash gets erased, including the bootloader, which sucks. For some reason, '-U application' or '-U apptable' command line options are not working.

Some thing tells me I need to go over my fuse settings again....

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

Thanks a lot!
-e option has solved my problem to program atxmega16a4u through serial port.
I used both xboot (compiled with avr-gcc 4.8.2) and avr1605 (compiled avr studio 5), and these work with avrdude command:

avrdude -V -v -c avr109 -p x16a4u -P /dev/ttyUSB0 -b 9600 -U flash:w:test.hex -e

Works even using -c avr911 option.
I use a simple FDTI USB-USART converter to program flash.

Stefano.

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

Adding the chip erase option does make this work for the xmega256a3 as well. I had tried doing a chip erase independent of the avrdude command but it still didn't work. Looking at the details it looks like if you don't do the chip erase then no data is ever written.

With -e option:

avrdude: Device signature = 0x1e9842
avrdude: erasing chip
avrdude: Send: e [65] 
avrdude: Recv: . [0d] 
avrdude: reading input file "twig_xmega256a3.bin"
avrdude: input file twig_xmega256a3.bin auto detected as raw binary
avrdude: writing flash (27832 bytes):

Writing |                                                    | 0% 0.00savrdude: Send: A [41] . [00] . [00] 
avrdude: Recv: . [0d] 
avrdude: Send: B [42] .

Without -e option:

avrdude: Device signature = 0x1e9842
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 "twig_xmega256a3.bin"
avrdude: input file twig_xmega256a3.bin auto detected as raw binary
avrdude: writing flash (27832 bytes):

Writing | #                                                  | 1% 0.00s ***failed; 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-e helped!!

GREAT THANKS!