dfu-programmer/dfu-programmer

dfu-programmer is a Device Firmware Update based USB programmer for Atmel chips with a USB bootloader

dfu-programmer

dfu-programmer is an implementation of the Device Firmware Upgrade class USB driver that enables firmware upgrades for various USB enabled (with the correct bootloader) Atmel chips. This program was created because the Atmel "FLIP" program for flashing devices does not support flashing via USB on Linux, and because standard DFU loaders do not work for Atmel's chips.

Check out the Atmel website for more information. They are kind enough to provide generally correct specifications this implementation is based on.

The project website is http://dfu-programmer.github.io and you can use that to check for updates.

All official builds and releases are on GitHub.

Simple install procedure for Unix/Linux/MAC

tar -xzf dfu-programmer-<version>.tar.gz # unpack the sources

or

git clone https://github.com/dfu-programmer/dfu-programmer.git

cd dfu-programmer # change to the top-level directory

If the source was checked-out from GitHub, run the following command. You may also need to do this if your libusb is in a non-standard location, or if the build fails to find it for some reason. This command requires that autoconf is installed (sudo apt-get install autoconf).

./bootstrap.sh # regenerate base config files

./configure # regenerate configure and run it

Optionally you can specify where dfu-programmer gets installed using the --prefix= option to the ./configure command. See ./configure --help for more details.

If usb library is not available try getting sudo apt-get install libusb-1.0-0-dev.

make # build dfu-programmer
sudo make install # install dfu-programmer

Instructions for installing autocompletion will also be displayed during make (or make bash-completion).

Build procedure for Windows

Building Windows apps from source is never quite as simple... Firstly you need to have MinGW and MSys with developer tools. Get them from http://sourceforge.net/projects/mingw/files/. See .github/workflows/build.yml for examples of building on Windows and the needed tools.

If you install the correct package with pacman, header and lib files will be installed in the correct locations.

• 32-bit: pacman -S mingw-w64-i686-libusb
• 64-bit: pacman -S mingw-w64-x86_64-libusb

Follow the same install instructions as above.

Windows Driver Files

Windows's built-in WinUSB driver should work out of the box.

Atmel FLIP

Atmel's FLIP programmer also uses libusb-win32, so we can take advantage of Atmel's official certified drivers.

Zadig

Zadig is another popular tool for managing the current USB driver for devices on your system. It can be used to install the libusb-win32, libusbK, WinUSB, or "USB Serial (CDC)" drivers. All but "USB Serial (CDC)" will work with dfu-programmer.

Testing & Coverage

Since most testing depends on hardware, we've set up a custom GitHub Action Runner on a dedicated Raspberry Pi. Read more about the tests here.

Currently Supported Chips

8051 based controllers

• at89c51snd1c
• at89c51snd2c
• at89c5130
• at89c5131
• at89c5132

AVR based controllers

• at90usb1287
• at90usb1286
• at90usb1287-4k
• at90usb1286-4k
• at90usb647
• at90usb646
• at90usb162
• at90usb82
• atmega32u6
• atmega32u4
• atmega32u2
• atmega16u4
• atmega16u2
• atmega8u2

AVR32 based controllers

• at32uc3a0128
• at32uc3a1128
• at32uc3a0256
• at32uc3a1256
• at32uc3a0512
• at32uc3a1512
• at32uc3a0512es
• at32uc3a1512es
• at32uc3a364
• at32uc3a364s
• at32uc3a3128
• at32uc3a3128s
• at32uc3a3256
• at32uc3a3256s
• at32uc3a4256s
• at32uc3b064
• at32uc3b164
• at32uc3b0128
• at32uc3b1128
• at32uc3b0256
• at32uc3b1256
• at32uc3b0256es
• at32uc3b1256es
• at32uc3b0512
• at32uc3b1512
• at32uc3c064
• at32uc3c0128
• at32uc3c0256
• at32uc3c0512
• at32uc3c164
• at32uc3c1128
• at32uc3c1256
• at32uc3c1512
• at32uc3c264
• at32uc3c2128
• at32uc3c2256
• at32uc3c2512

XMEGA based controllers

• atxmega64a1u
• atxmega128a1u
• atxmega64a3u
• atxmega128a3u
• atxmega192a3u
• atxmega256a3u
• atxmega16a4u
• atxmega32a4u
• atxmega64a4u
• atxmega128a4u
• atxmega256a3bu
• atxmega64b1
• atxmega128b1
• atxmega64b3
• atxmega128b3
• atxmega64c3
• atxmega128c3
• atxmega256c3
• atxmega384c3
• atxmega16c4
• atxmega32c4

Experimental support for ST cortex M4

• stm32f4_B
• stm32f4_C
• stm32f4_E
• stm32f4_G

dfu-programmer's Issues

Dynamic Library build scripts

So I think I said months ago that I'd share the scripts I made to build dfu-programmer as a dynamic library.
And then I lost them...

Fortunately I just found them again, cleaned them up a bit and have added a fork here:
https://github.com/EspoTek/libdfuprog

Happy DFUing, everyone. :)

exit code is 5 after a successful erase

dfu-programmer return an exit code of 5 after successfully erasing a chip.

     target: atmega32u4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: erase
      quiet: false
      debug: 200
device_type: AVR
------ command specific below ------
   validate: true

...
dfu.c:238: ==============================
dfu.c:240: status->bStatus: errCHECK_ERASED (0x05)
dfu.c:241: status->bwPollTimeout: 0x0000 ms
dfu.c:243: status->bState: dfuERROR (0x0a)
dfu.c:244: status->iString: 0x00
dfu.c:245: ------------------------------
atmel.c:787: Region is NOT bank.
....
atmel.c:795:  First non-blank address in region is 0x0.
atmel.c:866: Flash NOT blank beginning at 0x0.
Not blank at 0x1.
commands.c:88: erase 0x6FFF bytes.
atmel.c:329: atmel_erase_flash( 0x7fff83f43ba0, 4 )
Erasing flash...
....
dfu.c:238: ==============================
dfu.c:240: status->bStatus: errCHECK_ERASED (0x05)
dfu.c:241: status->bwPollTimeout: 0x0000 ms
dfu.c:243: status->bState: dfuERROR (0x0a)
dfu.c:244: status->iString: 0x00
dfu.c:245: ------------------------------
Success

echo $? -> 5

Add support for at89c51cc03

I was wondering if anyone could add support for the AT89C51CC03 chip? That would be fantastic!

Wish: Erase user page

AFAIK dfu-programmer's "erase" command does not erase the user page of AVR32. It would be great to let dfu-programmer also erase the user page (perhaps when executed with a certain option), similarly to what "batchisp" can do.

8051 board recommendation?

Hello,

Can anyone recommend an 8051 board which is easy to use and program with dfu-programmer?

Thanks!

Handling of write locked Application_Table section of ATXMEGA devices

Hi,

I'm working on an atxmega32c4, but from reading the code I'm pretty sure that the issue will exist for other devices with this flash size.

I use the Application_Table as an extension of the Bootloader section (i.e. all dfu-related stuff is in the Bootloader section, but more init code is present in the Application_Table), and this code must be protected against erases/flash. (Typically, this means that our BLBB and BLBAT lock bits are set to "WLOCK", while the BLBA and LB are left to NOLOCK).

In this case, I have the following issues:

1. The erase command does not work (but this seem unrelated to dfu-programmer, and needs to be checked from the bootloader, as it should still erase the Application section)
2. The blank check always return an error, because obviously the Application_Table section is never blank, so each flash action requires --force.
3. After flashing, the validate fails because the Application_Table section is still not blank (thus different to what is requested in my .hex file). The validate fails only on data outside region (so the actual flash works).

I've developed a few workarounds on my fork of the project (basically I added a command line flag telling to ignore "outside region" errors while flashing), but I'm pretty sure that a more clean handling could be done (typically, by ignoring only the errors in the Application_Table section if a given flag is set, instead of ignoring all errors). If you're willing to integrate my changes, I can clean them and make a pull request.

Regards,
Nicolas.

reconfigure not possible with 0.7.0

The 0.7.0 release is missing NEWS and ChangeLog, preventing one from re-generating the configure script. The reconfigure is needed when cross compiling as the provided configure hardcode the include path of libusb.

How to add support for atxmega128a1?

I see there's support for atxmega128a1u, but not the atxmega128a1.
They're very similar devices as far as I know.
What would need to be done to add support for it?
Happy to do the work and submit a PR is someone can push me in the right direction.

Use of debug variable

Debug and Trace output, and the programming progress bar are currently all tied to the value of the debug level variable.

I think the progress output should be (mostly) independent of debug. It doesn't work well if debug is on, but there is no way to turn progress off when debug is off. Seems like this should be independently controllable.

Related to this, progress is disabled for Atmel when stderr is not a TTY, but not for STM32. This should be standardised.

Secondly, debug output is enabled per module depending on debug level. So if you want to see DFU debug you also have to see atmel, intel_hex, arguments and command debug. It might be more sensible to make these independently selectable. As part of this I would see function trace being application-wide, but a separate selection from the module debug.

GitHub Actions is updating Node from v12 to v16

Some of our release dependencies are using an old version of Node and GitHub Actions are complaining.

Action run showing the warning: https://github.com/dfu-programmer/dfu-programmer/actions/runs/3295512448

Warning text:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: softprops/action-gh-release

Query - erase - application space and bootloader space separate on atxmega

Hi -
not sure if this is an issue, but I thought an atxmega32a4u had 32k application space and a separate 4k bootloader space.
However executing an erase leads to a message:
"Checking memory from 0x0 to 0x6fff", which is NOT the full 32k.

Cheers, Adam

Silent failure of "erase"

I just ran into a case where "erase" fails silently, and then also came across this message describing the problem:
http://sourceforge.net/p/dfu-programmer/mailman/message/27986707/

Looking at the github source the flawed logic still seems to be present. Has this been fixed some other way that I am not seeing or is it still a valid bug?

Split-off a shared library for use in front-ends

This would make it easier to use front-ends to update firmwares, especially for devices with wider commercial availability. In my case, I'd like to add a firmware upgrade facility for the Retrode, which uses an AVR chip internally.

See https://github.com/hughsie/fwupd/issues/128

Support partial flash verification and erasure

A common use case is to store configuration data in dedicated pages of flash on a per device basis.
This is in fact already partially supported by dfu-programmer with it's --serial-number option. Unfortunately the included options are a little under-featured.

Specifically, dfu-programmer does not currently support validating or erasing only part of a chip.

This would be a nice feature to have.

For instance only erasing most of the pages on a device:

dfu-programmer atmega32u4 erase --range=0x0000-0x6000

Or to only validate the range of memory that was actually written:

dfu-programmer atmega32u4 flash --validate-partial program.hex

As it stands, I need to --suppress-validation completely to get dfu-programmer to work with my workflow.

If I want to validate the flash that was loaded, I need to read the flash off the device manually and write my own validator that only checks the flash region that is specified in the original program.hex file.
This just seems like a feature that would be well suited to dfu-programmer.

potential configure.ac issue

I'm not entirely sure, but this may be an issue in the configure.ac file:
https://bugzilla.redhat.com/show_bug.cgi?id=2152666

warning: 'libusb_set_debug' is deprecated

main.c:81:9: warning: 'libusb_set_debug' is deprecated [-Wdeprecated-declarations]
        libusb_set_debug(usbcontext, debug );
        ^
/opt/local/include/libusb-1.0/libusb.h:1351:1: note: 'libusb_set_debug' has been explicitly marked deprecated here
LIBUSB_DEPRECATED_FOR(libusb_set_option)
^
/opt/local/include/libusb-1.0/libusb.h:70:50: note: expanded from macro 'LIBUSB_DEPRECATED_FOR'
#define LIBUSB_DEPRECATED_FOR(f) __attribute__ ((deprecated))
                                                 ^
1 warning generated.

Misuse of autoconf features in configure.ac causes multiple problems

Hi, there are multiple problems with the way dfu-programmer's configure.ac uses autoconf features which cause build problems for me on macOS. This was reported to MacPorts here. I reported it as an autoconf bug but now believe it's just a bug with how dfu-programmer is using autoconf.

Symptoms of the problems include this configure output:

checking for ANSI C header files... no

checking stdlib.h usability... yes
checking stdlib.h presence... no
configure: WARNING: stdlib.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: stdlib.h: proceeding with the compiler's result
checking for stdlib.h... yes

In the current version of autoconf it is assumed that ANSI C header files exist and the header "presence" checks have been removed, but the reason why these tests are failing here is that they are trying to run $CPP but $CPP is unexpectedly empty (autoconf should have set it to a reasonable value) so the check fails with errors like:

./configure: line 4534: conftest.c: command not found

Because it thinks ANSI C header files don't exist, it doesn't define things like HAVE_STRING_H, resulting in subsequent checks encountering implicit declaration of functions, which hasn't been allowed since C99 was introduced 2 decades ago and which is now forbidden in the version of clang that comes with Xcode 12 and later (in order to accommodate Apple Silicon processors), so subsequent checks fail:

checking for working memcmp... no

because:

configure:4774: checking for working memcmp
configure:4817: cc -o conftest -Werror=implicit-function-declaration -I/opt/local/include/libusb-1.0   conftest.c  -L/opt/local/lib -lusb-1.0 >&5
conftest.c:53:7: error: implicitly declaring library function 'memcmp' with type 'int (const void *, const void *, unsigned long)' [-Werror,-Wimplicit-function-declaration]
  if (memcmp(&c0, &c2, 1) >= 0 || memcmp(&c1, &c2, 1) >= 0)
      ^
conftest.c:53:7: note: include the header <string.h> or explicitly provide a declaration for 'memcmp'
conftest.c:67:2: error: implicitly declaring library function 'strcpy' with type 'char *(char *, const char *)' [-Werror,-Wimplicit-function-declaration]
        strcpy (a, "--------01111111");
        ^
conftest.c:67:2: note: include the header <string.h> or explicitly provide a declaration for 'strcpy'
2 errors generated.

I am manually adding -Werror=implicit-function-declaration to CFLAGS because I am using clang from an older version of Xcode but I want to see the problems that users of Xcode 12 or later would see so that I can try to fix them.

I have libusb 1 installed with MacPorts. If I use the --disable-libusb_1_0 configure flag these problems go away, pointing to a possible problem within the configure.ac code that checks for libusb 1.

Although I don't think it's directly contributing to this problem, it looks suspicious to me that the code is modifying CFLAGS; configure.ac files should never do that. It's explained in the automake documentation:

You should never redefine a user variable ... in Makefile.am

You should not add options to these user variables within configure either

It also looked suspicious to me that autoconf directives that I would have assumed should be done as part of the initial setup (AC_HEADER_STDC, AC_C_CONST, AC_TYPE_SIZE_T, AC_FUNC_MALLOC, AC_FUNC_MEMCMP) are instead being performed near the end of configure.ac. I tried moving AC_HEADER_STDC to near the top of configure.ac (right after AC_PROG_CC). This fixes the problem that $CPP was empty but does not fix the problem that HAVE_STRING_H et al are not defined. Also moving AC_C_CONST, AC_TYPE_SIZE_T, AC_FUNC_MALLOC, AC_FUNC_MEMCMP to the top after AC_HEADER_STDC fixed the second problem. Now HAVE_STRING_H et al are defined, reflected in the additional configure output showing headers being checked, and it can detect that memcmp does exist:

checking for an ANSI C-conforming const... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for size_t... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working memcmp... yes

So this diff is enough to solve these problem:

diff --git a/configure.ac b/configure.ac
index 233b7b1..482ead7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,6 +13,17 @@ AM_MAINTAINER_MODE
 # Checks for programs.
 AC_PROG_CC

+# Checks for header files.
+AC_HEADER_STDC
+
+# Checks for typedefs, structures, and compiler characteristics.
+AC_C_CONST
+AC_TYPE_SIZE_T
+
+# Checks for library functions.
+AC_FUNC_MALLOC
+AC_FUNC_MEMCMP
+
 # Checks for libusb - from sane-backends configuration

 dnl Enable libusb-1.0, if available
@@ -64,17 +75,6 @@ if test "$HAVE_USB" = "yes"; then
 fi


-# Checks for header files.
-AC_HEADER_STDC
-
-# Checks for typedefs, structures, and compiler characteristics.
-AC_C_CONST
-AC_TYPE_SIZE_T
-
-# Checks for library functions.
-AC_FUNC_MALLOC
-AC_FUNC_MEMCMP
-#AC_CHECK_FUNC([memset], :, [AC_CHECK_LIB([libc], [libc])])

 AC_CONFIG_FILES(fedora/dfu-programmer.spec Makefile docs/Makefile src/Makefile)
 AC_OUTPUT

A different fix was submitted in PR #22, to change how libusb 1 is detected and to no longer modify CFLAGS, which also works for me to solve the preceding problems. In fact the PR says it was merged:

@swinman merged commit 0daf3d8 into dfu-programmer:master on Feb 18, 2016

I'm confused therefore that the latest commit to master was actually made in Jan 19, 2016 and there is no sign of this commit on master. Perhaps you rewrote history afterward to remove this commit, perhaps because of problems reported on Windows? If so, please don't rewrite history in public repositories; it makes things hard to follow. That PR should be reopened so that whatever the problems were can be fixed and it can be re-merged.

With either my fix above or the one from #22, master then builds. 0.7.2 does not build; it fails with:

atmel.c:285:31: error: implicitly declaring library function 'malloc' with type 'void *(unsigned long)' [-Werror,-Wimplicit-function-declaration]
    bout->data = (uint16_t *) malloc( total_size * sizeof(uint16_t) );
                              ^
atmel.c:285:31: note: include the header <stdlib.h> or explicitly provide a declaration for 'malloc'
1 error generated.

This was already fixed in 26d96f2 by moving the code that calls malloc from atmel.c to intel_hex.c which already includes <stdlib.h>. A new version of dfu-programmer containing this fix and a fix for the other problems reported in this issue should be released.

Atmel Flip driver support: libusb0 vs libusb-win32

Hey,
is there a difference between libusb0 and libusb-win32? They seem to be the same thing according to the Zadig driver installer.
I ask because the Readme says the Atmel FLIP driver (libusb-win32) is supported but Atmel Flip seems to use the libusb0 driver that is no longer supported. If there is no difference it would be great if the Readme would be updated to clarify that the Atmel Flip driver is no longer support. Also if possible could the software give a warning when the libusb0 driver is used. On version 1.0.0 the libusb0 driver still seems to work to some extend but causes some weird behaviour compared to 0.9.0.

Add support for at32u4 chips

It would be nice if this also worked for the newer chips being used in the Arduino micro boards. Let me know if anyone has tested this or if there is simple work to add support I'll be happy to help.

Thanks!

Missing git tag for 0.7.2 release?

My assumption was that it is commit b1a75c0 - perhaps the tag just didn't get pushed?

No Checksums?

I can't find any published checksums for your releases. Can you confirm?

No device present

I try to flash ATmega16U2 (in Rumba board) with dfu-programmer running on mac os 10.11.6.

$ lsusb
Bus 020 Device 031: ID 03eb:204b Atmel Corporation RUMBA - ATmega 2560 co  Serial: 5533033373035130B171

I changed VID in the source code, but still getting error

sudo ~/not-my-projects/dfu-programmer/src/dfu-programmer atmega16u2:20,31 flash RUMBA_16U2_USB2Serial.hex --force --debug 99999999
     target: atmega16u2
    chip_id: 0x204b
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 99999999
device_type: AVR
------ command specific below ------
   validate: true
   hex file: RUMBA_16U2_USB2Serial.hex

dfu.c:422: dfu_device_init( 1003, 8267, 0x7fff543788b0, true, false )
dfu-programmer: no device present.

Same result for Ubuntu 16.04.1

$ lsusb
Bus 002 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project

$ sudo ~/dfu-programmer/src/dfu-programmer atmega16u2:2,5 flash ~/Desktop/RUMBA_16U2_USB2Serial.hex --force --debug 99999999
     target: atmega16u2
    chip_id: 0x204b
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 99999999
device_type: AVR
------ command specific below ------
   validate: true
   hex file: /home/orangeudav/Desktop/RUMBA_16U2_USB2Serial.hex

usb_set_debug: Setting debugging level to 99999999 (on)
dfu.c:422: dfu_device_init( 1003, 8267, 0x7fff8bd3c6e0, true, false )
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_devices: Found 005 on 002
skipped 3 class/vendor specific interface descriptors
usb_os_find_devices: Found 004 on 002
usb_os_find_devices: Found 003 on 002
usb_os_find_devices: Found 002 on 002
skipped 1 class/vendor specific interface descriptors
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 001 on 001
dfu-programmer: no device present.

specifying the bus and device doesn't work

If I specify the bus and device number it doesn't find the chip.

$  lsusb
Bus 004 Device 002: ID 8087:8001 Intel Corp. 
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:8009 Intel Corp. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 2109:0810  
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 012: ID 03eb:2ff4 Atmel Corp. 
Bus 001 Device 006: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB

$ sudo dfu-programmer atmega32u4:1,12 get bootloader-version
dfu-programmer: no device present.

but if i type the command with out address it works:

$ sudo dfu-programmer atmega32u4 get bootloader-version
Bootloader Version: 0x00 (0)

ATxmega32C4 flash command vs. lockbits

Hello,
I would like to flash ATxmega32C4 under Linux with dfu-programmer. When I set LB lockbit to RWLOCK dfu-programmer can erase application in flash memory, but cannot flash new application (log is in attachment). Everything works fine with Atmel FLIP, so there is something wrong with dfu-programmer.
log.txt

lost libisl-15.dll

hi,
When I use msys to build this procedure for Windows,it reminds me that I am missing libisl-15.dll file. How to deal with it and where to download this file?
Thank you

dfu-programmer error on user page

I am using dfu-programmer to test programming an atmel MCU. it progrmmed the main applicaiton .hex file to the flash memory is fine. But when I have a smaller .hex file to program to the user page, the software shown error on complaining the size of the .hex file. Looks like it expect to at lease have the fine size great or equal to the page size which is 512 bytes. so I create a .hex file with 512 bytes but still show hte same error as (when turn debug option on ):

atmel.c:1629: Expected message length of 592, got -5.

I checked the source code and knew the location where thrown the error but don't know why.

If someone programmed the user page before and can help me out.

The command I used to program user page is where have problem.
dfu-programmer at32uc3c0512 flash --user --debug=51 applicationheader.hex --force

but the same command to program flash pages are Ok.
dfu-programmer at32uc3c0512 flash --debug=51 application.hex --suppress-bootloader-mem -- force

Thanks,
Chester

atmega32u4 - error while flashing

Hi 👋

I can't seem to get any application to flash via DFU. I am using a custom board w/ the atmega32u4-MU MCU and I am using the USB-DFU .hex image provided by Microchip on their website. You can find it at the very bottom of the page in the Embedded Software section on the summary page for the ATmega32u4.

Once I flash that image, I get what appears to be a working DFU bootloader to enumerate

[356247.965362] usb 3-4.2.2.4.4: new full-speed USB device number 125 using xhci_hcd
[356248.072389] usb 3-4.2.2.4.4: New USB device found, idVendor=03eb, idProduct=2ff4, bcdDevice= 0.00
[356248.072402] usb 3-4.2.2.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[356248.072406] usb 3-4.2.2.4.4: Product: ATm32U4DFU
[356248.072409] usb 3-4.2.2.4.4: Manufacturer: ATMEL
[356248.072411] usb 3-4.2.2.4.4: SerialNumber: 1.0.0

When I attempt to flash a test .hex image that turns on an LED, I get the following error.

⚡ ./dfu-programmer atmega32u4 flash NEW_PROJECT-v0_1_0.hex --debug 5
     target: atmega32u4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 5
device_type: AVR
------ command specific below ------
   validate: true
   hex file: NEW_PROJECT-v0_1_0.hex

Checking memory from 0x0 to 0xFF...  Empty.
0%                            100%  Programming 0x100 bytes...
[ X  ERROR
Memory write error, use debug for more info.

My immediate assumption is that this DFU firmware I found is not compatible with dfu-programmer. If that is the case, do you have any .hex images for compatible DFU bootloaders I could try? I saw mention in the docs that Atmel/Microchip provides chips pre-loaded with a boot-loader, but none of my ICs so far have had one.

Thanks!

Building under MSYS2

Is it possible to compile dfu-programmer for MSYS2 (MinGW32/64)? I'm trying to create a proper package for it but keep running into obstacles (probably because I'm not well versed in the intricacies of GCC).

I've tried all sorts of things to avoid having to link against the supplied libusb-win32:

• Simply removing the --disable-libusb_1_0, which does compile with the libusb package added, but requires the device driver be set to WinUSB
• Keeping --disable-libusb_1_0 and patching #include <usb.h> to #include <libusb-compat/usb.h> as the mingw-w64 runtime usb.h appears to be getting picked up first. This also compiles, but still needs WinUSB since libusb-compat is just a wrapper around libusb 1.0

Now I've given in and done what the readme says, and copied over libusb.a and usb.h...and the linker still isn't happy.

Here is my PKGBUILD file, for reference:

# Maintainer: fauxpark <[email protected]>

_realname=dfu-programmer
pkgbase=mingw-w64-${_realname}
pkgname=${MINGW_PACKAGE_PREFIX}-${_realname}
pkgver=0.7.2
pkgrel=1
pkgdesc='Device firmware update based USB programmer for Atmel chips'
arch=('x86_64' 'i686')
license=('GPL')
url='https://github.com/dfu-programmer/dfu-programmer'
makedepends=(
    "${MINGW_PACKAGE_PREFIX}-gcc"
)
source=(
    "https://downloads.sourceforge.net/project/dfu-programmer/dfu-programmer/${pkgver}/dfu-programmer-${pkgver}.tar.gz"
    "https://github.com/dfu-programmer/dfu-programmer/raw/master/windows/libusb.a"
    "https://raw.githubusercontent.com/dfu-programmer/dfu-programmer/master/windows/usb.h"
)
noextract=('libusb.a' 'usb.h')
sha256sums=(
    '1db4d36b1aedab2adc976e8faa5495df3cf82dc4bf883633dc6ba71f7c4af995'
    'b52834f0ecb33e558691419898c576ea8e8c460b0672d4d4974b1a720faddb86'
    'a7cc341d5587ce8e6f971359e008bcccd01691b864928203efa449839a6edb7b'
)

prepare() {
    cp ${srcdir}/libusb.a ${MINGW_PREFIX}/lib/libusb.a
    cp ${srcdir}/usb.h ${MINGW_PREFIX}/include/usb.h
}

build() {
    cd ${srcdir}/${_realname}-${pkgver}

    ./configure --disable-libusb_1_0
}

package() {
    cd ${srcdir}/${_realname}-${pkgver}

    make DESTDIR="$pkgdir" install

    rm ${MINGW_PREFIX}/lib/libusb.a
    rm ${MINGW_PREFIX}/include/usb.h
}

Which causes ld to produce a bunch of undefined reference to \usb_*``, and a few variations on the following in config.log:

skipping incompatible C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../lib/libusb.a when searching for -lusb

Any ideas?

not passing "--debug 99" leads to "no device found"

I'm on arch linux with dfu-programmer v0.7.2.

Reproducably, when I just do, e.g.,

# sudo dfu-programmer atmega16u2 erase

... it fails with "dfu-programmer: no device present."

Running sudo dfu-programmer atmega16u2 erase --debug 99 works ~ 3 out of 4 times.

WORD1 forced to be E11EFFD7

The following observations were tested on Windows 10 and Debian 9 for AT32UC3A3256 and AT32UC3C2512:

I noticed that after if I use flash, erase, getfuse, or readfuse, my WORD1 always gets set to E11EFFD7 afterwards, which renders my microcontroller useless because WORD1 = E11EFFD7 means that ISP_FORCE = 1 and the microcontroller will be forced into DFU mode no matter what.

I did some debugging using GDB and narrowed down the problem to the dfu_transfer_out() function. That is, before dfu_transfer_out() my WORD1 is a pre-defined value (e.g. E11EFDD9) and after dfu_transfer_out WORD1 is now E11EFFD7.

AT90USB64 (Retrode 2) is not recognised

Might be that I'm doing something wrong, but I can't seem to connect my Retrode 2 (Which it seems to have an AT90USB64 in it)
It just keeps saying that the device is not present.
I've tried with a 6 and a 7 at the end, as otherwise the program will just give me a list of compatible devices.

Am I missing something or is this device not supported?



Thanks for taking the time to look at this :)

dfu error how to fix

root@kali:~/dfu-programmer# make
Making all in src
make[1]: Entering directory '/root/dfu-programmer/src'
make  all-am
make[2]: Entering directory '/root/dfu-programmer/src'
gcc -DHAVE_CONFIG_H -I.    -Wall -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c:29:10: fatal error: usb.h: No such file or directory
 #include <usb.h>
          ^~~~~~~
compilation terminated.
make[2]: *** [Makefile:377: main.o] Error 1
make[2]: Leaving directory '/root/dfu-programmer/src'
make[1]: *** [Makefile:266: all] Error 2
make[1]: Leaving directory '/root/dfu-programmer/src'
make: *** [Makefile:348: all-recursive] Error 1
root@kali:~/dfu-programmer# make install
Making install in src
make[1]: Entering directory '/root/dfu-programmer/src'
gcc -DHAVE_CONFIG_H -I.    -Wall -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c:29:10: fatal error: usb.h: No such file or directory
 #include <usb.h>
          ^~~~~~~
compilation terminated.
make[1]: *** [Makefile:377: main.o] Error 1
make[1]: Leaving directory '/root/dfu-programmer/src'
make: *** [Makefile:348: install-recursive] Error 1

Release asset `dfu-programmer-1.0.0.tar.gz` is missing file `update-bash-completion.sh`

Release asset dfu-programmer-1.0.0.tar.gz is missing file update-bash-completion.sh

./configure && make fails with make: *** No rule to make target 'update-bash-completion.sh', needed by 'dfu_programmer'. Stop..

0.9.0 works fine.

is this abandonware?

I find this program very helpful, and I wonder why it's not updated anymore. I hope that someone may pick it up! Thanks to the developers for the great work done until now.

Use the product name to auto-identify the chip?

I notice the family code and product code in

dfu-programmer/src/atmel.c

Line 282 in 5254ee4

{ 0x05, 0x02, (ADC_AVR32 | ADC_XMEGA), offsetof(atmel_device_info_t, productName) },

Would it be possible to use this information rather than specifying the full chip ID for each operation? I can't find any ATMEL documentation which maps the values found there to actual chip descriptors. Thanks!

Error when opening on Windows 8.1 / 'unable to start correctly (0xc000007b)'

Hi!

I am trying now to update the firmware under the Windows 8.1 and I keep the messages about dfu-programmer being broken. I have copied the libusub0 dlls to the app's directory (from all architectures), but it has not helped. Error is shown both with and w/o Admin privileges.

OS Windows 8.1 x64

Error looks like this:

---------------------------
dfu-programmer.exe - Application Error
---------------------------
The application was unable to start correctly (0xc000007b). Click OK to
close the application.
---------------------------
OK
---------------------------

And without the library copied:

The program can't start because libusb0.dll is missing from your computer. 
Try reinstalling the program to fix this problem. 

Just for completeness - I have downloaded it from project's page [2] -> [1]

[1]
https://sourceforge.net/projects/dfu-programmer/files/dfu-programmer/0.7.0/
[2] https://dfu-programmer.github.io/

PS Same with 0.7.2

dfu programmer without root linux

Hi guys. I use the dfu in Windows and mac and dont need any type of permission. Just run and its ok.
Now in ubuntu i'am facing some problems because i cant run it with sudo.. We can do any trick to pass this ? I already tried the parameter usbcore autosuspend = -1 but still the same ..
I really need to run it without sudo because i'am doing that behind a app.
Thank you in advance

Using deprecated GitHub Action feature set-output

GitHub Actions deprecated a feature soon after we started using Actions.

We need to update the actions slightly to address this.

Action run showing the warning: https://github.com/dfu-programmer/dfu-programmer/actions/runs/3294850093

Warning text:

The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

error code 254 on launch

Hi - I'm getting an error code of 254 on the launch command which traces to line 899 in src/atmel.c. I haven't previously received this error (or haven't noticed it), but it doesn't seem like any of this code was recently changed.. There are two dfu-download commands in the atmel_start_app_reset function and the error is happening on the second of the two calls. It seems likely that only one call is required.. Does anyone know off hand if this is the case? I'm about to search for documentation..

$ dfu-programmer at32uc3b1256 launch --debug=100
target: at32uc3b1256
chip_id: 0x2ff6
vendor_id: 0x03eb
command: launch
quiet: false
debug: 100
device_type: AVR32
------ command specific below ------
no-reset: 0

atmel.c:891: atmel_start_app_reset( 0x7ffc2ca42eb0 )
atmel.c:899: dfu_download failed.
$ echo $?
254

and it causes my Makefile to terminate...

Release asset dfu-programmer-1.1.0.tar.gz is missing most header files

Hi,
I tried to compile dfu-programmer-1.1.0.tar.gz from releases page, but many header files are missing:
src/libdfu.h
src/arguments.h
src/dfu-device.h
src/atmel.h
src/intel_hex.h
src/dfu.h
src/commands.h
src/util.h
src/stm32.h

Can you check this? Thanks!

Issue with erase and flash for atxmega128a3u

Hi,

I am not sure if this is related to #26, but I have also problems erasing and flashing an XMega
with dfu-programmer (git head/5254ee and version 0.6.1).
But my bootloader seems to be fine, because Atmel's programmer Flip (I am using Version 3.4.7) from an XP Virtual Machine can successfully erase and flash.

I am not sure if it matters that Flip does more steps (open, erase, blank check, program, verify) than dfu-programmer (erase, flash).

But Flip submits different data to flash.
Flip (flip_allsteps_usbdump.txt, line 190) starts with "698: 0100 0000 0279"
while dfu-programmer (dfuprogrammer_eraseflash_usbdump.txt, line 82) starts with "1104: 0100 0000 03ff".

Also Flip's data stops much earlier (last common: ffcf) while dfu-programmer continues with tons of "ffff" and finishes with "0000 0000 1044 4655 0110 ffff ffff ffff".

I have also attached the debug output of dfu-programmer (dfuprogrammer_eraseflash_debugoutput.txt)

I am pretty clueless what this all means, but if I can provide some more information / try something that might help resolve this issue please let me know.

Thanks for your awesome software!
Daniel

flip_allsteps_usbdump.txt
dfuprogrammer_eraseflash_usbdump.txt
dfuprogrammer_eraseflash_debugoutput.txt

dfu-programmer doesn't work on 32-bit Windows

On 32-bit Windows, the filename it should be looking for is libusb0_x86.dll.

Missing the 0.7.0 tag and possibly the 0.7.1 tag

I just noticed that the 0.7.0 release tag is missing from the GitHub repo, and if 0.7.1 was recently released, then it's missing too. :-)

ATxmega64A3U:Error programming EEPROM

Hello, you out there,

maybe someone can help me with this issue:
We have problems programming the EEPROM memory of the ATxmega64A3U with dfu-programmer.exe:

• It works well for the FLASH memory of the ATxmega64A3U.
• It works well for the EEPROM of an ATxmega128A3U
• But we get errors when trying to program the EEPROM of the ATxmega64A3U.
• This issue does NOT happen on all PCs. It works on some, it fails on others. The firmware of the devices i.e. the bootloader is always the same.
• When it works on a PC, it always works. If it fails, it always fails.
• I know, there WAS an issue with the PID of the ATxmega64A3U which formerly identified it as an ATxmega64A4U. We have already installed the fixed atmel_usb_dfu.inf

I've been crawling through the debug outputs and through the code of dfu-programmer.exe, but i can't seem to figure out the reason.

I have attached the debug output of dfu-programmer.exe for the ATxmega64A3U (failed) and the ATxmega128A3U (passed). Comparing the files with examdiff or similar tool shows it immediately.
Further attached in the .zip the batchfiles i used to invoke dfu-programmer.exe.

Does this seem familiar to anyone? Any idea, what this behaviour and error might reason from?

Any help is appreciated. Thank you all.

Andi

P.S.

• No EESAVE fuse is used
• Fuses are identical for both devices / both controllers:

  FUSES =
    {
      .FUSEBYTE0 = FUSE0_DEFAULT, // JTAGID
      .FUSEBYTE1 = FUSE1_DEFAULT,	// WDT defaults
      .FUSEBYTE2 = BODPD_SAMPLED,
      //.FUSEBYTE3 reserved
      .FUSEBYTE4 = FUSE4_DEFAULT, // RSTDSBL, SUT, WDLOCK, JTAGEN
      .FUSEBYTE5 = (BODLEVEL_2_8 & BODACT_SAMPLED)
    };

P.P.S.: It DOES work using the Atmel FLIP software!

debugdump_eeprom_64a3u.txt
debugdump_eeprom_128a3u.txt
Batchfiles.zip

Specifying usb-bus and usb-addr does not work on Windows

I'm trying to reliably program two different devices that are connected to my system with two different programs. These two devices are based on the same ATmega32u4 based hardware, so I need to get slightly clever with how I detect the different devices.

I've written a little Node.js script to scan (via node-usb) and filter for the devices I want based on a USB descriptor string (ID 3).

import { getDeviceList } from "usb";

getDeviceList()
  .filter(d => d.deviceDescriptor.idProduct === 12276)
  .filter(d => d.deviceDescriptor.idVendor === 1003)
  .forEach(device => {
    device.open();

    device.getStringDescriptor(3, (err, desc) => {
      device.close();

      console.log(`Found ${desc} at ${device.busNumber},${device.deviceAddress}`);
    });
  });

This gets a "busNumber" and a "deviceAddress" as reported from libusb, as far as I can tell.

Trying to call dfu-programmer atmega32u4:1,41 erase, I get "dfu-programmer: no device present.", no matter what arguments I've tried. I've even written a little script to walk through all possible bus numbers & device addresses and it's found no matching devices...

Looking into the source a little bit, I see "found device at ..." is printed if debug is enabled.

Trying that, without specifying the port, I see:

> dfu-programmer atmega32u4 erase --debug 1000
     target: atmega32u4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: erase
      quiet: false
      debug: 1000
device_type: AVR
------ command specific below ------
   validate: true

dfu.c:414: dfu_device_init( 1003, 12276, 0063FE78, true, false )
dfu.c:431: found device at USB:1,0
dfu.c:663: Found DFU Inteface: 0
dfu.c:293: dfu_abort( 0063FE78 )
[...]

So it looks like the device is at "1,0" but if I specify a bus or device address of 0, I always get the "Unsupported target ..." message.

So, is it even possible to use the usb device/address on Windows? I've seen the discussions at #33 about which IDs to use, but those are restricted to Linux. Here, I'm using the numbers reported by the internal debug and it's still not working as I expect.

What am I doing wrong?

cat: dfu_completion :No such file or directory

After running ./bootstrap.sh this is what terminal is displaying

dfu.c:961: Unknown error 0xfffffff7 (-9)

issue with the ATXMEGA128a3u.
Error message:

dfu.c:961: Unknown error 0xfffffff7 (-9)

We've tested this on Linux ARM (dfu-programmer versions 0.6.1 - 0.7.2) and Linux x86 environment (Ubuntu, dfu-programmer version 0.6.1).
Application 'Flip' is working fine.

We're calling the application in following way:

DEBUGLEVEL=999999
TARGET=atxmega128a3u
FW_FILE=DL_3.50_640T_V1.5.hex
#FW_FILE=FW_3v51_ErrorLogger.hex

sudo dfu-programmer $TARGET erase --debug $DEBUGLEVEL
echo "------------------------------------------"
echo "Return from erasing: $?"
echo "------------------------------------------"

sudo dfu-programmer $TARGET flash $FW_FILE --debug $DEBUGLEVEL
echo "------------------------------------------"
echo "Return from flashing: $?"
echo "------------------------------------------"
sudo dfu-programmer $TARGET start

Attached the extended log file
dfu-programmer.ext.debug.log

Can somebody help us?
Best Regards,
Helmut

Originally posted by @SaubaSogI in #29 (comment)

Trying to use dfu-programmer with at90usb1286

While running in ubuntu I seem to be unable to flash. I am trying to program with ./dfu-programmer at90usb1286 flash TwinkleFox.ino.hex.

I am able to program with Flip. And after programming with flip I am able to erase with dfu-programmer. Yay!

However, re-flashing with dfu-programmer gives me an error of the form:

sudo ./dfu-programmer at90usb1286 flash TwinkleFox.ino.hex 
Checking memory from 0x0 to 0x20FF...  Empty.
0%                            100%  Programming 0x2100 bytes...
[ X  ERROR
Memory write error, use debug for more info.

I can provide any debug info you ask for, but don't want to flood you with stuff you don't care about. Any help you can provide is appreciated.

Build on Windows

I'm trying to debug #62 by building my own copy of dfu-programmer.exe. I tried plenty of things on my personal machine and kept running into issues with paths, msys, cygwin, tried in multiple bash shells.

I'm now trying to build on GitHub Actions. It was easy enough to get macOS and Linux building but Windows is still giving no end of trouble.

I've tried the instructions in the README and the release_proc.txt files to no avail. Any better instructions out there? How are the releases normally handled?

AT90USBKEY2: dfu-programmer doesn't work

I'm trying to use dfu-programmer with AT90USBKEY2 evboard from Atmel. It doesn't work. Flip software from Atmel works well.

I'm using an hex file as an application example. Erase operation is ok. Flash operation isn't ok:

dfu-programmer at90usb1287 flash diana5prog.hex
0%                            100%  Programming 0x8D80 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x1E000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
Validating...  ERROR
31580 invalid bytes in program region, 0 outside region.
FAIL
Memory did not validate. Did you erase?

I read the Flash memory after dfu-programming (with a JTAG programmer) and the content is really different than the original hex file. There identical sections, but there are different sections.
It seems some section are written at a different address (maybe at a different Flash page?).

Again, Flip software works well.