XMEGA fuse programming problem using avrdude

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

Hello,

 

I use avrdude as my favourite tool for programming Atmels processors.   But I had problems for a while programming ATXMEGA256A3U fuses; it never works the first time:

/usr/local/bin/avrdude -c jtag2fast -P usb -p x256a3u -u -U fuse0:w:0xff:m -U fuse1:w:0x88:m -U fuse2:w:0xfe:m -U fuse4:w:0xf6:m -U fuse5:w:0xe2:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

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 "0xff"
avrdude: writing fuse0 (1 bytes):

...........

avrdude: reading input file "0xf6"
avrdude: writing fuse4 (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of fuse4 written
avrdude: verifying fuse4 memory against 0xf6:
avrdude: load data fuse4 data from input file 0xf6:
avrdude: input file 0xf6 contains 1 bytes
avrdude: reading on-chip fuse4 data:

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

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xfe != 0xf6
avrdude: verification error; content mismatch

avrdude done.  Thank you.

second time is fine:

/usr/local/bin/avrdude -c jtag2fast -P usb -p x256a3u -u -U fuse0:w:0xff:m -U fuse1:w:0x88:m -U fuse2:w:0xfe:m -U fuse4:w:0xf6:m -U fuse5:w:0xe2:m

avrdude: AVR device initialized and ready to accept instructions

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

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 "0xff"
avrdude: writing fuse0 (1 bytes):
...........

avrdude: reading input file "0xf6"
avrdude: writing fuse4 (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of fuse4 written
avrdude: verifying fuse4 memory against 0xf6:
avrdude: load data fuse4 data from input file 0xf6:
avrdude: input file 0xf6 contains 1 bytes
avrdude: reading on-chip fuse4 data:

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

avrdude: verifying ...
avrdude: 1 bytes of fuse4 verified
avrdude: reading input file "0xe2"
avrdude: writing fuse5 (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of fuse5 written
avrdude: verifying fuse5 memory against 0xe2:
avrdude: load data fuse5 data from input file 0xe2:
avrdude: input file 0xe2 contains 1 bytes
avrdude: reading on-chip fuse5 data:

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

avrdude: verifying ...
avrdude: 1 bytes of fuse5 verified

avrdude done.  Thank you.

Is the writing of the first fuses preventing the writing of fuse4?   Have I missed something?

 

 

It's probably a mistake putting that in the same post but maybe it is related: programming of the ATXMEGA128A4U fuses never works.

 

/usr/local/bin/avrdude -c jtag2pdi -P usb -p x128a4u -u -U fuse1:w:0x88:m -U fuse2:w:0xff:m -U fuse4:w:0xf3:m -U fuse5:w:0xf6:m

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e9746
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 "0x88"
avrdude: writing fuse1 (1 bytes):
avrdude: 1 bytes of fuse1 written
avrdude: verifying fuse1 memory against 0x88:
avrdude: load data fuse1 data from input file 0x88:
avrdude: input file 0x88 contains 1 bytes
avrdude: reading on-chip fuse1 data:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x88
avrdude: verification error; content mismatch

avrdude done.  Thank you.

When I (very reluctantly) start avrstudio it shows fuse 1 as correctly programmed to 0x88.    Is it possible that that has to do with missing fuse0?    I tried to set fuse0 to 0x00 but then avrdude complains (correctly) that there is no such thing as fuse0.  

 

Can somebody confirm / deny the problem?    Any workarounds?

 

Regards,

Hagen

.

Last Edited: Thu. Feb 19, 2015 - 12:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Concerning 128a4u, There are no fuse entries for 128a4u in my older copy of the avrdude.conf file.  That could be your problem.  You may be able to figure out what the entries should be by looking at the entries for another Xmega.

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

Don't know anything about Xmega fuses but do any of the bytes have unused bits? If so then be wary of avrdude as it will only accept one state for unused (0 I think). So if you had a fuse byte where only the bottom 3 bits were relevant and you programmed 0xFD to set the bottom 3 bits to 0x05 I think it would complain when verifying that the top 5 bits were not 0xF8. You would need to use 0x05.

 

Just thought I'd mention this in case it's relevant.

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

@steve17: There must be entries for the fuses because avrdude recognises them.    I think the problem may be that it programmes the right one starting from 1 but when verifying it starts reading from 0 (which does not exist).    I have to check the avrdude.conf file (I have to admit I did not know this file exists) and possibly add fuse0 and program it to 00.

 

@clawson: I am not aware that I am setting any bits that do not exist.   I have the settings from the data sheet and confirmed them with avrstudio.    The xmega256a3u also works fine at the second attempt.   This is reproduceable.

 

Is there anybody here in the forum that has programmed the fuses in this particular device using avrdude (contents does not matter)?

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

Seggt mol Lüüd, hett denn nich eener sodennig Deel inner Klüterkraamkisten to´n pröven wat nu de Schose is?

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

Nobody here with an Xmega256A3U or Xmega128A4 to double check if fuse programming works with avrdude?   

Is the problem possibly fixed already so that I have to install a newer version of avrdude?

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

I've got the hardware already hooked up, but my brain doesn't have a clue.  I've always used avrdude with a bootloader, not with my JTAGICE mkII.  I've never used avrdude for fuses either.

 

I tried to make a batch file to read the fuses based on a previous post in this thread but it doesn't work.  I'm assuming jtag2pdi refers to my programmer.  It exists, Studio finds it.

 

 

 

avrdude -c jtag2pdi  -P usb -p x128a4 -U fuse1:r:fuse.bin
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2103)

avrdude done.  Thank you.

 

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

Steve,

 

If you have Studio then have you installed the "libusb filter driver" for avrdude to use? The fact is that without it you are going to have two things competing to access your Atmel USB tools. Studio supplies and installs (lots of) Jungo/WinDriver USB drivers for the Atmel tools. This is how Studio (or rather atbackend in Studio) talks to the JTAGICEmkII etc.

 

avrdude on the other hand is built to interact with "libusb". libusb won't be able to "see" the Atmel tools as the Atmel/Jungo/Windriver drivers will be in charge. So you need the "filter driver". It knows that it needs to talk to the Jungo and not direct to the USB hardware. With thta in place avrdude talks to the filter driver, the filter driver talks to Jungo and Jungo talks to the actual hardware.

 

(there's 100's of prior threads about this - I think Google will find the thing you need if you just Google "libusb filter driver").

 

EDIT: OK I think this is what you need: http://sourceforge.net/projects/...

 

The bin/ directories have install-filter*.exe programs to use.

 

EDIT2: wow, talk about a coincidence! I was looking up the posts of a user for a completely different reason and found this post from him:

 

https://www.avrfreaks.net/comment...

 

where he details what was done to make use of those 1.2.6 files.

Last Edited: Wed. Apr 8, 2015 - 11:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,

 

maybe you can use the same command line where I failed:

avrdude -c jtag2pdi -P usb -p x128a4u -u -U fuse1:w:0x88:m -U fuse2:w:0xff:m -U fuse4:w:0xf3:m -U fuse5:w:0xf6:m

 

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

clawson wrote:

Steve,

 

If you have Studio then have you installed the "libusb filter driver" for avrdude to use?

Thanks for the info.  I think I will drop this project.  I learned something anyway.  It seems I could do it, but I don't need any more complications now.  Studio is the way I do fuses.

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

steve17 wrote:
Studio is the way I do fuses.

If you are happy with it that's fine.   I do not use Studio.  Not in a development environment.   And certainly not in a production environment.

 

So anybody out there using a professional operating system and can do the test ?

Last Edited: Thu. Apr 9, 2015 - 07:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a ATxmega32A4U that is connected via PDI.    It runs fine with a JTAGICE-2 or a Dragon.   Currently I am using it with an ATMEL-ICE.

 

I see little point in your question unless you can specify what  "professional operating system" is required.

 

And whether you would believe the behaviour of a x32a4u !!!

 

David.

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

What version of avrdude do you have?  

32A4U should have the same fuses as the 128A4U but it would still not be testing the same.