Avrdude 6.1 no worky with com ports.

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

I can't get avrdude 6.1 dated March 13 2014 to work with com ports.  Neither real ports nor virtual ports.  It does work well using flip2.

 

avrdude 5.2 works okay with com ports but it doesn't have flip.

 

I have attached the avrdude 6.1 failure log using -v.   It starts and ends correctly except for the verification failure.  However between the start and end there are over 7300 lines that just say "***failed;"

Attachment(s): 

Last Edited: Sun. Nov 23, 2014 - 01:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Windows or Linux? And what's the command line? (neither are clear from that .txt file).

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

Windows.  I should have mentioned that.  I suspect that has something to do with the problem.  Apparently avrdude was developed for Linux and is mainly used there.

 

Here are two command lines, actually the contents of .bat files.  com9 is a real serial port.  com16 is a virtual serial port.  Both work fine with avrdude 5.2 but fail miserably with avrdude 6.1.

avrdude -c avr911  -p x128a4  -P com9 -b 115200   -U flash:w:debug/CDC_boot_next.hex

avrdude -c avr911  -p x128a4  -P com16 -b 115200   -U flash:w:debug/CDC_boot_next.hex

 

 

Here is a command line that uses flip2.  It works well with avrdude 6.1 but avrdude 5.2 doesn't understand flip2.

avrdude -c flip2  -p x256a3bu           -U application:w:debug/CDC_boot_next.hex
 

 

 

 

 

 

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

I made a mistake posting the command lines for avrdude 6.1 using a com port.  The "flash" needs to be changed to "application.  This is a command line I use for 6.1.

avrdude -c avr911  -p x128a4  -P com16  -U application:w:CDC_boot_good/debug/CDC_boot_good.hex

 

Well actually I tried it both ways.  Maybe "flash" is correct when using avr911, but that doesn't work either.

 

 

Last Edited: Mon. Nov 24, 2014 - 02:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think that I have got a 'modern' avrdude on any PC.     Mostly avrdude.5.10 or avrdude.5.11

 

Since AVR911 is nothing more than a serial protocol,   it should just depend on a suitable bootloader being present on your target AVR.

 

I would guess that any 'modern' avrdude has been extensively used with stk500v1 or stk500v2 protocols on a COM port.

 

Perhaps the 'modern' avrdude.conf has some typos for the Xmega entries.

 

Yes,  it would be nice to use avrdude instead of FLIP.    I will see if I can find a ready-built modern avrdude.exe and try it for myself.

 

David.

 

Edit.    Just downloaded avrdude6.1 from Savannah "avrdude-6.1-mingw32.zip"

Last Edited: Mon. Nov 24, 2014 - 03:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have any kind of terminal program you can confirm, for a start, that COM9 can actually be opened.

 

Also I don't know at what stage avrdude.exe starts telling you when it's trying to open COM9 and how that went but it seems likely it's with more than one "-v". You can add up to 4 and it gets more and more verbose as you do.

 

I'd like to know whether it's saying it simply cannot open COM9 or whether that bit went OK and then it was later, when writing bytes to it that it didn't get the responses it expects.

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

clawson wrote:

Do you have any kind of terminal program you can confirm, for a start, that COM9 can actually be opened.

Certainly.  I use com9 all the time.  Furthermore avrdude 5.2 works fine with com9.

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

I'm pretty sure it is opening com9.  I don't have a serial port monitor handy. 

 

I do have a USB monitor handy though.  com16 is a virtual serial port that is used by my USB CDC bootloader. 

 

I just got a log of the USB data when avrdude 6.1 used com16.  avrdude did the initialization stuff okay.  It got the chip signature, etc.  Then it skipped the writes to flash entirely and then it read the flash, no doubt doing the verify.  As the program avrdude was trying to write to my Xmega already was present on the xmega, the verify worked, avrdude was happy, and thanked me, despite the thousands of "***failure;" things it put in the log.

 

So the question is, why does avrdude 6.1 do everything correctly except it doesn't write to flash?

 

 

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

If you look at the log I attached to my first post, you will see it read stuff out of the Xmega.

 

If it was just guessing, it made a hell of a lot of lucky guesses because it shows the correct bootloader name, software version, auto address increment, buffer size, device code and device signature.

Here's an excerpt:

 

 

 

             Description     : Atmel AppNote AVR911 AVROSP

Connecting to programmer: .
Found programmer: Id = "XmegaBl"; type = S
    Software Version = 1.0; 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.exe: devcode selected: 0xfffffffa
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e9746

 

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

david.prentice wrote:

Edit.    Just downloaded avrdude6.1 from Savannah "avrdude-6.1-mingw32.zip"

I think that's where I got mine.

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

I built AVR1605 from CV example and installed it on a xmega128A1 XPLAIN board.

 

avrdude6.1 connects ok but fails with writing to flash

avrdude5.11 works fine.

 

avrdude6.1 seems to work ok with -c arduino

 

So I suspect there is a problem with AVR911 rather than the COM port.

 

I will try installing AVR911 bootloader on a regular Mega tomorrow.

 

David.

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

Yeah I suspect something like that.  Using avr109 causes the same failure.  I see the thousands of "***failure;" things.   Using avr910 causes avrdude to abort because the programmer doesn't support x128a4u.  Using stk500v2 causes avrdude to report timeouts immediately and doesn't progress further.  Using arduino doesn't work either but at least it fails gracefully.

 

 

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

Using any of these "serial" protocols should not care what the target is.    i.e. it just sends / receives packets over RS232.

 

I can try various protocols on many different Mega or Tinys.

 

I only have 128A1 and 32A4U Xmega chips.

 

Yes,   I would like to use -c flip2 with the 32A4U

I really don't mind which serial protocol to use with an Xmega.   Just as long as it works with avrdude.

 

David.

 

Edit.   I installed an AVR911 bootloader for a ATmega324P.    avrdude6.1 worked ok.

 

Last Edited: Wed. Nov 26, 2014 - 03:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I installed an AVR911 bootloader for a ATmega324P.    avrdude6.1 worked ok.

Interesting.  So it looks like Xmega is the problem.

 

If you are asking for Xmega bootloader advice, I can tell you all bootloaders suck, but some suck more than others.smiley

 

I'm guessing the DFU/flip2 may be the best but I haven't looked at it much.  I bought an Xmega 256a3bu Xplained board some time ago but haven't used it.  A couple days ago I decided to see if I could put one of my programs in it.  I guessed it came with a DFU bootloader and I noticed avrdude 6.1 claimed to have flip1 and flip2.  I figured if flip1 was good, flip2 would be better.  smiley  So I tried it and it worked.

 

Atmel supplies the DFU bootloaders but you will probably want to tailor them for your board.  That always seems like a freakin' nightmare to me.  They just can't make it simple.

 

For com port bootloaders, I use Bandtank's.  It is about as easy to tailor as it gets as long as you are comfortable using make.  It uses AVR911.  One thing I didn't like about that is it erases EEPROM as well as application flash when it gets the Erase command from avrdude.  I commented out the code that erases EEPROM.

 

I'm working on my own AVR911 bootloader for Xmegas.  It uses USB CDC so avrdude sees it as a com port.  So far it only writes and reads flash and only for Xmegas with 256 byte flash pages.  

Last Edited: Wed. Nov 26, 2014 - 05:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never really looked at Xmega bootloaders.    Since I have a 32A4U 'protoboard' that I can connect Shields to,   It would be quite nice to bootload rather than use Dragon and PDI.    (I can always PDI if I want to hardware debug.)

 

I am sure that the avrdude6.1 'feature' is simple to fix.   I will have a look later.

 

David.

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

I have found suitable AVR911 bootloaders from bandtank: https://github.com/bandtank/Xmega_Bootloader

It looks very well organised and very easy to configure.

 

It works fine with avrdude-5.11.1

 

I then tried it with avrdude-6.1 and captured the traffic with a Saleae Logic Analyser.

 

The problem is simple:   it sends the "g" command (Start Block Flash Read) instead of the "B" (Start Block Flash Load)

 

So it is obviously going to fail!

I tried avrdude-6.1 with avr109 and this fails too.

 

This must come down to an "avrdude feature".   The obvious fix is to go back to avrdude-5.11 and forget about flip2.

 

David.

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

david.prentice wrote:
The problem is simple:   it sends the "g" command (Start Block Flash Read) instead of the "B" (Start Block Flash Load)

David.

Well, that is basically what I reported.   All bootloaders read back the flash after writing by using the 'g' command.  It's the verify phase.  This verify works okay.  But as you noted it is supposed to write the flash first and it doesn't do that.  Those 7300 errors are apparently being displayed during the write phase.

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

david.prentice wrote:

The obvious fix is to go back to avrdude-5.11 and forget about flip2.

 

David.

Au contraire, mon frère.   flip2 works well, as I have previously reported.  This protocol uses USB to communicate with the DFU bootloader in the Xmega. 

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

Yes,   I know that flip2 works well with avrdude-6.1

 

I possess a 128A1 and a 32A4U.   I can use AVR911 with both chips if I use avrdude-5.11

I really don't want to have to change avrdude version for each chip.   i.e. v5.11 for 128A1 and v6.1 for 32A4U

 

I will take a 'closer' look at avr109 tomorrow.    I suspect that v6.1 has protocol issues with avr109, avr910, avr911.

It appears to be fine with stk500v1 and stk500v2.   Please do not take my comments for gospel until I have studied each 'session'

 

I am surprised that there has not been more whingeing if there really is a feature with v6.1

 

It may just be that bootloader users have not seen any need to install v6.1

I only did it because you said that v6.1 supported DFU (-c flip2)

 

David.

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

I think avrdude is primarily a Linux tool.  It may be the port to Windows that is the problem.

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

Yeah, having two versions where each version requires it's own .conf file can be a pain.

 

I was able to fix that here.  I have two folders that are in my PATH.  I put avrdude 5.2 with it's .conf in one folder.  I put avrdude 6.1 with it's .conf in another folder.  I renamed avrdude.exe version 6.1 to avrdude_61.exe.  So if I want to run the old version I run avrdude.  If I want to run the new version I run avrdude_61.

 

 

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

Ah-ha.  My earlier comments were premature.

 

Avrdude-6.1 has a special feature:

Reading | avrdude-6.1-mingw32\avrdude.exe: Send: s [73] 
avrdude-6.1-mingw32\avrdude.exe: Recv: A [41] . [95] . [1e] 
################################################## | 100% 0.00s

avrdude-6.1-mingw32\avrdude.exe: Device signature = 0x1e9541
avrdude-6.1-mingw32\avrdude.exe: 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-6.1-mingw32\avrdude.exe: reading input file "david.hex"
avrdude-6.1-mingw32\avrdude.exe: writing flash (20 bytes):

If you use a specific -e switch,  you erase the application memory.    Avrdude-6.1 works fine.    Of course most programming software expects you to make a specific erase before programming the flash.

 

The traditional avrdude as a default detects a "program flash" and does a chip-erase.   So people have got lazy and omit the -e switch.

 

This is good news.    I just need to add "-e" to the command in my Tools menu and I can use v6.1

 

David.

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

Thanks.  I'll check it out later.

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

Okay, I got it working.

 

It's still a bug in avrdude.  If nothing else, avrdude should tell you to add the -e and not put out 7300 meaningless error messages.  Actually I found using the -D command also makes avrdude work.  Of course if the memory isn't erased and your bootloader doesn't do it on it's own, the programming will be faulty.

 

I didn't know AVR911 had a page erase command.  I never saw that in the bandtank version.

 

In any event in my bootloader I always ignore the erase chip command.    I always erase each page just prior to writing it. 

 

What the erase chip command does in the Bandtank version is erase app memory and EEPROM.