Not exact on Windows, but on other systems where I have been able to get dfu-programmer up and running:
a) use lsusb to get the Bus (x) and the Device Number (y)
b) use sudo dfu-programmer:x,y erase for the first step of firmware upgrade.
Without sudo you will not have the HW access , and the device might not be found with x,y given
Greetings. I am having the same issue and would really appreciate help.
After the “erase” command succeeded, dfu-programmer reports:
dfu-programmer: no device present
The device is present according to lsusb:
Bus 002 Device 007: ID 03eb:2ff1 Atmel Corp.
I tried the solution provided above, but the result does not change:
dfu-programmer at32uc3a3256s:2,7 flash --suppress-bootloader-mem firmware_V0.47.0.hex
Still gives “no device present”.
Thanks in advance. The device is currently not responsive and contains a valid key.
Hi,
on which system are you working? As far as I know lsusb is a UNIX command? So you are not on Windows as the OP?
If so: did you execute the command with root permissions?
Kind regards
Alex
Ubuntu 18.04
Eventually, I would like to use it on Mac OS (I needed to downgrade the firmware to make it work with Mac OS), but the flashing tool does not compile on the Mac. I was able to compile it on Ubuntu.
Yes, executing as
sudo dfu-programmer …
Hi,
does the Nitrokey App recognize the NK Storage?
Why not using the binary? But compiling it yourself probably is not the cause…
I guess: you did try plugging in and out, rebooting your system, used different USB ports etc?
Have you tried ‘erase’ again? It should state
Checking memory from 0x2000 to 0x3FFFF... Empty.
Chip already blank, to force erase use --force.
So if you can access the device with erase I don’t see why you shouldn’t with the flash command, yet 
- The Nitro key App no longer recognizes the device at all.
- I did not know there was a binary, I went back and installed it from the distro, successfully. No change in results. Still getting “no device present to all commands”.
- Yes, I did try plugging in/out, rebooting, several times.
- Yes, I also did try re-erasing, bu the erase command also gives “no device present”.
- Again I was only able to access the device with the erase command once, no longer.
Here is the verbose lsusb output of the device (bus/device updated since replug:
Bus 002 Device 003: ID 03eb:2ff1 Atmel Corp.
Couldn’t open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x03eb Atmel Corp.
idProduct 0x2ff1
bcdDevice 10.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 27
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 2
iInterface 0
Device Firmware Upgrade Interface Descriptor:
bLength 9
bDescriptorType 33
bmAttributes 15
Will Detach
Manifestation Tolerant
Upload Supported
Download Supported
wDetachTimeout 0 milliseconds
wTransferSize 65535 bytes
bcdDFUVersion 1.01
And the --debug 9 output of the command:
$ dfu-programmer at32uc3a3256s:2,3 erase --debug 9
target: at32uc3a3256s
chip_id: 0x2ff1
vendor_id: 0x03eb
command: erase
quiet: false
debug: 9
device_type: AVR32
------ command specific below ------
validate: true
dfu-programmer: no device present.Greetings again.
I went on an old Windows machine and installed the binary of dfu-installer. Also installed the driver successfully and the system recognized device. However, the erase command result is identical to the one seen on Linux, including debug details as above.
This was just a test, and I really dislike working with unsigned binary executables on systems like Windows, so I would really appreciate continuing the ticket in Linux and Mac OS terms, if possible.
best regards.
Hi!
- Have you tried running without specifying the device bus and device numbers? E.g.:
dfu-programmer at32uc3a3256s flash --suppress-bootloader-mem firmware_V0.47.0.hex
- What is your dfu-programmer version? Mine is
0.7.2.
That, finally resolved the bricked device issue. The device is now operational on firmware version 0.47.
That, however, only solved the technical problem created by the downgrade of the firmware from 0.48 to 0.47, as proposed by Alex to a request by fernando in Lots of issues with encrypted storage (and password safe) on Mac
However, the majority of the multiple issues described by fernando in that post are unresolved by the downgrade to 0.47 .
Namely:
- Clicking the Eject button or using other GUI means in the Finder to eject disks always result in the volumes (encrypted or unencrypted) reappearing, meaning that one cannot remove the key or lock the encrypted volume safely; the only way one is able to get the volumes to stay unmounted is by ejecting the “Nitrokey Nitrokey Storage Media” entries from Disk Utility – but this only works sometimes; ejecting works fine on Linux – this behavior is unacceptable is unchanged in 0.47.
- Data corruption happens between sessions of locking and unlocking the encrypted volume, and appears unrecoverable. It is unsure if this is due to the inevitable unsafe removals described above, or to otherwise faulty software, or both.
- The device (the app) reports frequent disconnections and reconnections despite a healthy appearing USB connection (not experienced in other operating systems running on the same hardware, so assumed to be due to flaky coding).
- On a good note, the GnuPG integration (on the Mac, using the Suite) appears unaffected by these problems, though I will need to run more tests before permanantly committing keys to this apparently very unreliable device, with a very fragile software implementation.
I will continue the Mac OS testing further and report issues, but I am sorry to report that the App 1.1 and firmwares 0.47 and 0.48 barely qualify as alpha software on Mac OS.
We can continue the discussion in Lots of issues with encrypted storage (and password safe) on Mac - where it’s more appropriate.
best regards,
Are you using Secure Input in Terminal or password dialogs?
PS Could you copy your post there?
szszszsz: thanks for the comments.
- Yes, I had tried running the command w/o the bus.device parameters.
- I used dfu-programmer 0.7.2 in all three environments.
- only executing it as root (use sudo -i to start a bash as root) appeared resolve the problem, with seems a little extreme.
best regards,
marky
I just did. - We should continue there.
password dialogs pop up. I have not tried to modify that behaviour in gpg.
I might get accustomed to this, but working with devices on low-level usually need root privileges. On Ubuntu one could configure udev to grant the privileges to user automatically - perhaps similar mechanism is available on MacOS but I am not aware of it (yet).
To take a conclusion from this discussion, which one would suit you:
- Provided a signed
dfu-programmerbinary for MacOS (run with root privileges), - A way to run the programmer without
sudoon MacOS, - Other (your solution here).
szszszsz:
The question is about making the management of the device reasonably user-friendly, in a multi-platform environment.
I did not have the time to debug and compile the tool on the Mac, but the OS is just another open-source Unix system, Darwin, and accessing low-level operations as root is not that different on the Mac. It should suffice to open a shell as root before executing the command.
What would suit me is simply good programming, good documentation, and clarity for all platforms that the product promises to be compatible with.
What would suit the everyday Mac user is certainly an Apple-signed app that integrates a decent firmware upgrade tool, which can be run with administrative privileges (GUI equivalent of sudo), - but probably not “as root”.
If I understand well, dfu-programmer is GPL open source, multi-platform, so incorporating it in a decent multi-platform Nitrokey App ought not to be impossible.
Of course. None of that is required. I was just referring to the uneasiness of using sudo and with which of the solutions would you be happy with. Sorry if that sounded unkind.
I see. Perhaps we could provide some GUI based on dfu-programmer, but that would still require admin. privileges, which essentially is what root has. Nevertheless, a signed programmer application is a good proposition.
You are right. The only constraint is time, hence my feedback gathering and suiting to the user without unnecessary work.
I hope we are getting there.
Hello guys,
I have same problem no device found.
i am using win 7, latest dfu version, UNO r3 board (m16u2).
When i try to erase i got the error no device found.
i tried every possible thing on web. yet my problem is solved.
We support solving problems only with our specific device model, which use DFU - Nitrokey Storage. We are not using Arduino at all, sorry.
can you provide some link’s regarding my quetion ???