DFU-Programmer tips & tricks


I recently got a Atmel AT90USBKey to play around with.  I’m going to use it to prototype a USB controller for the MRF49XA transceiver I made a while ago.  That post is still in progress, but I had trouble getting started with DFU-Programmer on the mac, so I thought I’d make a post about those problems so it may help others having the same trouble.  I know that I found next-to-nothing when I was googling for it.

I didn’t have too much trouble installing DFU-Programmer, the version included in macports works just as well as the version I compiled from source.  The first problem I encountered was a weird memory error when I tried to dump the device memory.  When I’m just starting with something, I usually don’t jump in, guns-blazing, and start erasing and flashing stuff.  I start by dumping memories, usually it’s not going to break something that already works.  In this case, I ran up against a brick wall.

$ dfu-programmer at90usb162 dump --debug 5 > temp
     target: at90usb162
    chip_id: 0x2ffa
  vendor_id: 0x03eb
    command: dump
      quiet: false
      debug: 5
device_type: AVR
------ command specific below ------

Request for 12288 bytes of memory failed.

There is literally no reason I can think of for this error to occur, it’s not using very much memory, and I’ve never seen a malloc fail when there is a reasonable amount requested.  I’ve searched for about 2 days for the answer, and I’ve still come up with nothing.  The only hits I’ve seen are simply source listings for DFU-Programmer, where the printf for the error is!  Getting around it (temporarily, even!) is a multi-step process, and requires a device erase (which makes it just about useless):

  1. Erase: dfu-programmer at901287 erase –debug 5
  2. Reboot into the boot loader (again)
  3. Erase (again, because a write-protect error: see below)
  4. Flash device: dfu-programmer at90usb1287 flash file.a90 –debug 5
  5. Dump flash memory: dfu-programmer at90usb1287 dump –debug 5 > out.dump

Eventually, it worked.  I’m not at all happy with the performance of dfu-programmer on the mac.  I’m considering forking it and making a proper mac application, but I’m not sure I’m willing to support it at the moment.  Ultimately, though, it does work, it’s just not as functional as I had hoped.

The write-protect error I mentioned above looks like this:

     target: at90usb162
    chip_id: 0x2ffa
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 5
device_type: AVR
------ command specific below ------
   validate: true
   hex file: USBKEY-series6-ms_df-2_0_2.a90

Device is write protected.
Error while flashing.

This error is strange (I’ve never set the write protect flag!), but easy to fix.  It is common for micro controllers to clear the write-only flags when the part is erased.  That’s the solution here, just erase it:

dfu-programmer at90usb162 erase

Now, you should be able to program the device.  Even when I hadn’t set the protection flags (knowingly, anyway) I got the write protect error.

The moral of the story is that dfu-programmer doesn’t work very well on the mac, and the magic fix seems to be erasing and rebooting the part often.  Good luck!  If you have noticed something stupid I’m doing, I’m all ears.  It seems like others haven’t had these problems, so I’d love to hear if there’s something I’m doing wrong.

Note that the AT90USBKey was provided by Element 14 in exchange for writing this post.

, , , , ,

  1. #1 by dext0rb on May 7, 2012 - 6:08 am

    Hi there,

    I had similar trouble flashing my atmega32u4 from OS X with dfu-programmer, so I followed your hint to erase before programming. Erasing then programming worked…but…I guess erasing wiped out the DFU bootloader as well, as I cannot get the device to enumerate in DFU mode again. I don’t think you should be able to erase the bootloader, so is there something else I am missing? (I am grounding HWB when powering up to get it into the bootloader mode and nothing happens.)

    Thanks

  2. #2 by hpux735 on May 7, 2012 - 6:17 am

    Correct, the boot loader is locked. I’m not sure why it wouldn’t be enumerating now… Are you using your own PCB, or the AT90USBKey? I had problems with a board I made myself not enumerating well, also. It was a mystery why.

  3. #3 by laban on January 5, 2014 - 4:10 am

    I am having some issues when trying to program an atxmega256a3bu. the device lock bits are set to 0xFC, locking the device from read and write. When using the FLIP tool in windows It states that the device is protected (this is correct) until I erase the device, then the protection is gone and it is ok to upload and verify until I reset the device the next time.

    However when using the dfu-programmer (ver 6.2) in ubuntu I have issues. I can only program the device if I don’t set the lock bits. If I use the protection like I do with the FLIP tool in windows I get an error.

    I first erase the device:
    dfu-programmer atxmega256a3bu erase

    then try to program it I get an error:
    dfu-programmer atxmega256a3bu flash splash.hex
    Error while flashing.

    any ideas?

  4. #4 by hpux735 on January 5, 2014 - 10:29 am

    Sorry, I have no idea. I haven’t tried setting any of the lock bits on an Atmel. I know that the PIC micro controllers work the same way (you can erase a lock bit, but only when you erase an entire device). I suppose that it’s possible that the open source dfu-programmer doesn’t know how to deal with lock bits.

(will not be published)

Please complete this capcha. I get almost 1000 spam comments a day! * Time limit is exhausted. Please reload CAPTCHA.