Digistump Forums
The Digispark => Digispark (Original) Support => Topic started by: earckens on November 14, 2016, 09:44:18 am
-
Currently I am unable to get a Digispark to get recognised on a Windows 7 64 bit laptop. Several months ago there were no problems, first install and all went fine: connecting, downloads from Arduino 1.6.7 IDE.
After several months of no activity with Digispark on my laptop I try again and no succes:
every time the usb connection displays "Unknown Device".
libusb-win32 Usb Devices is installed, with Digispark Bootloader driver and with the DigiUSB driver.
I had to install these both drivers using the manual hardware wizard described by emertonom in http://digistump.com/board/index.php?action=post;board=4.0
However, even after this install, no succes, still "Unknown Device".
When looking into the "Unknow Device" properties, hardware id' show "unknown", the INF file name is c:\Windows\INF\usb.inf, Supplier: Standard USB Host Controller
I have another Windows 7 laptop:no issues, and another Windows 8.1 laptop with no issues.
The trouble is that this laptop is my main workhorse and I badly need to get the Digispark recognised on it.
I spent the better part of the last few days ánd nights trying to solve this issue, including a change to the registry (remove USB flags), including completely deleting all usb devices in the device manager and restarting, including installing several times the drivers in the Digistump Drivers folder.
Even trying to connect after having the Arduino IDE download a program to the Digispark, connecting the unit: no succes, the Arduino IDE times out.
I would greatly appreciate any help on this issue!
Thanks in advance,
Erik
EDIT: I have several Digispark units, all fail on this laptop, all work on the other 2 (all are 64 bit systems).
-
Erik, I wished that I had a definitive answer to this behavior but all I have is a theory based on observation. It's my understanding that the Digispark is only in a state for about 5 secs were it will accept uploads then runs the loaded sketch. I'm currently running on WIN 8.1. Recently, I pulled the Digispark out of moth balls and found that it was not being recognized (according to Windows) when it had previously been working. I found that if I continuously disconnected and reconnected it on my USB port while upload was in progress and until it gone into an endless loop of not being recognized that it would eventually complete the upload. I know this sounds strange and I can't explain it or why this seems to work. My best guess is that there is some sort of race condition that exists that fails on some systems/configurations. Digistump's Erik may be able to explain the potential for this. But in any case just when I was about to give up thinking driver issue etc, I started to try resetting the Digispark (during the 60 second upload window) and tripped on it working. Finally, I also connect to the PC via a USB hub.
Worth a try if all else fails.
-
Hi exeng, I did try just now to plug and unplug several times during upload (multiple combinations of timings) but no combination of timings (from 1 second to several seconds of plug and/or unplug state) works.
I may be wrong but I would rather think of a wrong "binding" by Windows of the device, ie connecting it to the wrong driver (usb.inf instead of the libusb or digiusb.inf).
-
Again, can't explain why I can get it to work (BTW, I have to do this each time I want to upload). But it feels like a race condition were something is not in sync. Also, I've had to unplug and plug many times to get it into a loop of unrecognized, meaning it just keeps cycling and never runs the loaded sketch. Frustrating, and I wished I could put my finger on the problem but it would require knowing the internals of the loader.
-
exeng, that reasoning sounds right in respect to there only being a 5 second window to get the device identified and the driver bound... I wonder if it is worth trying one of the other versions of the firmware (http://digistump.com/board/index.php?action=post;quote=1711;topic=320.0;last_msg=8760) that uses a pin to tell it to go into programming mode - then the Digispark should stay in the bootloader for longer, and give windows the time it needs to install the correct driver? Something else that is worth looking into anyway... I imagine (hope, really) that it would stay in the bootloader until the upload has occured, as there is no longer a need to timeout to run the user sketch.
-
PeterF, good post you refer to; in there I found another interesting reference (re. issues with zeners and USB on digistump): http://digistump.com/board/index.php/topic,123.0.html
However, my initial suspicions (ie that there is a driver issue, where W7 binds the digistump to the wrong inf file) are still not contradicted. After connecting the digistump, a "Unknown Device" appears in the device manager. When I try to change the driver in the properties dialog for this "Unknown Device" in the device manager I am unable to change it to the libusb-win32 driver (Digispark Bootloader); "no better driver for this device found" ( :'(). I wonder if this has to do with the fact that it seems to be a 32bit driver (libusb-win32) whereas I have a 64 bit system?
But then in the other W7 64bit laptop where it is recognized there the "libusb-win32 Usb Devices" driver is listed in the device manager ONLY when the digispark is connected! Unplug it, the listing disappears... :o
I think something is wrong with the way the driver(s) are installed in my "defective" W7. But what?
EDIT: but then on my "working" W7 I have the same driver: "libusb-win32"...
-
One more thing checked at least I suppose... ok, are the drivers signed? I'm not able to check at the moment, but that is the usual bit 64bit driver issue I have, and you need to do the F8 on bootup to disable the stupid e device driver signature enforcement that Windows x64 bit has. Otherwise, there is some other driver tool (z-something) that might be worth finding again... as I think it had something to do with lib-usb and swapping in the correct driver if it was mis-associated or something.
-
One more thing checked at least I suppose... ok, are the drivers signed? I'm not able to check at the moment, but that is the usual bit 64bit driver issue I have, and you need to do the F8 on bootup to disable the stupid e device driver signature enforcement that Windows x64 bit has. Otherwise, there is some other driver tool (z-something) that might be worth finding again... as I think it had something to do with lib-usb and swapping in the correct driver if it was mis-associated or something.
Good to know, I check today and report back. I thought this was an issue with W8 only. No, driver signature is not unchecked on my machine. But neither is it on the other working W7 64bit machine. Anyway, it definitely is worth taking this step.
Erik
EDIT: changed to uncheck for driver signature; no result: "Unknown Device", even after reinstall of Digistump drivers
-
S - O - L - V - E - D !!!!! ;D
I watched this video https://www.youtube.com/watch?v=MmDBvgrYGZs that gave me the idea of looking into the way I had installed the drivers.
I had installed them by using the "Install Drivers.exe", which as it now appears installed the 32 bit drivers. When attempting to change the drivers for the Unknown Device, Windows kept telling me there were no appropriate drivers to be found when I directed the "manual driver install" to the folder with the Digistump drivers.
Subsequently, after this video, I reinstalled again using the driver install procedure so that the libusb would show up in the Device Manager. Then I went to that section (libusb-win32 Usb Devices), unsinstalled (IMPORTANT:) with the option uninstall drivers too activated.
Then I reinstalled but this time directly the DPinst64.exe!!!
Apparantly when using the generic driver installer it does not care which system you use, so if you are on a 64 bit system you are in trouble. Winx 64bit: always directly use the 64bit installer!
Big kudos to all here in attempting to help but especially to BrainyBits of the video tutorial above :)
Erik
EDIT: corrected typos
-
Oh duh! I had the exact same problem when I first tried using the DigiX on Win 7 x64... even had two separate command scripts so I always knew to run either the 32bit install or 64 bit install... lol... well, at least you got the daft thing working... and kudos to BrainyBits for making the video on it also.. I'm sure that video has helped a few people! ;)
-
I sincerely hope the people involved with drivers at Digistump will use this issue to change their driver install software ànd to include this in their tutorial at Wiki!
Maybe someone over there might acknowledge this here?
It will help a lot of people using their stuff: too many posts about this issue I have read when trying to solve my problem could have been resolved had this been elaborated more concisely on their site.
-
Erik, Awesome find. I'll have to check this out. I'm sick of my so called "workaround". It takes too long to get it in the right state and I'm sure it will eventually wear out my USB contacts. My issue is on a WIN 8.1 system. WIN 7 is fine. I'll report back if this fix works for me.
-
I have this installed - working - on a Win8.1 64bit system, it is imperative you disable the obligatory Windows requirement for driver signatures.
-
And now I take a two day break from anything Attiny related, my wife complained and suffered too much from the last preoccupied days and sleepless nights :-[
-
Thanks for the update. Now enjoy to the outdoors and get some sleep.
exen
-
Maybe someone over there might acknowledge this here?
Done. (Anyone with a forum account can contribute to the wiki ;) )
I added it to both the troubleshooting section and to the note at the start of the installation instructions where it was pointed out that the drivers needed to be installed manually.
Enjoy the "enforced" relaxation ;)
-
I can report that this has resolved my need to continually plug and unplug the digispark to get it to work (WIN 8.1) but it seems to only behave properly on a USB 3.0 port. My USB 2.0 ports still result in unknown device. I'll continue to observe that behavior and report back if I find anything interesting. At least now I have a solution. Just use the 3.0 port. Could be a red herring (sp?) but still see an issue on 2.0 ports that interestingly sometimes gets past the device descriptor and fails on set address.
Pete , Thanks for your proactive support.
Erik, (When you are rested) Thanks for finding the driver install video.
I don't use my Digisparks much, but when I do the last thing I need is to fight the update process. I only have 3. One is a time lapse controller for a hacked Sony digital camera, the 2nd a USBTinyISP and the 3rd for play, prototyping and experimentation.
-
I have to concur with exeng: the solution I mentioned yesterday is not robust. I still have issues with the device not being detected. And still on the same machine (Win7 64bit; while no problems with another Win7 64bit and Win8.1 64 bit), trying to use my fix, no avail :'(
-
Update: after another sleepless night with again problems of "Unknown Device" :'( (see previous post) I just got it working again; it has -in my case-, - I think - something to do with the driver version and install sequence.
Somehow the sequence of loading drivers, and which ones, seem to affect the results here. Also, it seems important to load them after removing the libusb and unknown devices TOGETHER with their respective drivers; and only then reinstalling them (before attempting to connect the digistump).
1. I have 64 bit installers dpinst-amd64.exe for drivers in my Arduino\drivers (C-drive) folder, version 2.1.0.0 dated 21/09/2016
2. then in Arduino\drivers\Digistump Drivers (from Digi wiki, downloaded last week): DPinst64.exe version 2.1.0.0 dated 08/04/2016 (I think 8th of april)
3. in Arduino\drivers\usbtinyisp_libusb_1.2.6.0 I have an installer_x64.exe (27/08/2015) as well as a folder amd64 and a folder ia64, both with libusb0.dll libusb0.sys both dated 27/08/2016.
Now, where is the catch? ???
-
With driver issues generally, I'd always recommend removing ("uninstall") (and also ticking the delete option if given) the driver, especially any hidden instances and then working back up. Fixes any annoying issues with half-installed and mis-matched driver/file versions, etc. One thing to be aware of if you don't already know is that driver installs (on windows at least) are associated with the USB port the device was detected in. Hence if you move your digispark to another port, it will have to go through the whole driver install and detection process. This is most noticeable with USB-to-serial adapters - the COM port changes depending on which USB socket you have the daft thing plugged into! :-/
DPInst is only a helper program - it's the Driver Package Installer provided as part of the Windows Driver developers kit - and AFAIK primarily just puts the files in the right place so the built-in driver autodetection in windows will find the driver files when it looks for them for a new unknown device. By rights you should be able to shove the digispark into a new computer, let the bootloader time out (the five second wait), go to the device manage, turn on the hidden devices, and then update the unknown device which you know to be the digispark by pointing it to the driver folder.
-
With driver issues generally, I'd always recommend removing ("uninstall") (and also ticking the delete option if given) the driver, especially any hidden instances and then working back up. Fixes any annoying issues with half-installed and mis-matched driver/file versions, etc. One thing to be aware of if you don't already know is that driver installs (on windows at least) are associated with the USB port the device was detected in. Hence if you move your digispark to another port, it will have to go through the whole driver install and detection process. This is most noticeable with USB-to-serial adapters - the COM port changes depending on which USB socket you have the daft thing plugged into! :-/
DPInst is only a helper program - it's the Driver Package Installer provided as part of the Windows Driver developers kit - and AFAIK primarily just puts the files in the right place so the built-in driver autodetection in windows will find the driver files when it looks for them for a new unknown device. By rights you should be able to shove the digispark into a new computer, let the bootloader time out (the five second wait), go to the device manage, turn on the hidden devices, and then update the unknown device which you know to be the digispark by pointing it to the driver folder.
Not only should you exclusively use the initial USB port, I found out that I also used that port for a wireless Logitech keyboard; as soon as I plug that unit in another USB port I do again get "Unknown Device"!
When I remove the Logitech USB unit from its non-familiar port, then reinstall the Dgistump Bootloader from the menu "Reinstall older hardware" (right-click on the top of all devices in device manager), choose the libusb-win32 Usb Devices and there the Digistump Bootloader, install: and hop, the device reappears in the device listing.
Next, restart Arduino, get a little program to download to the digistump, insert the sucker, and bingo! Download proceeds.
I repeated this last step at least ten times, each time removing the digistump from the usb port and reinserting when Arduino asks for it: each time it works.
Lessons:
1. use a dedicated USB for digistump only, do never plug any device that was in that usb port elsewhere in another usb port, never
2. only insert the digistump in its dedicated USB socket when asked for it, remove straight after download
3. before first use: clean ALL old, unknown etc devices together with their drivers
4. right after "point 3." install sequence I used with succes: (post 12:04 of today): 1, 3 and 2 (PeterF you may disagree but this worked for me time and again the last couple of miserable days :'(
5. watch the video on https://www.youtube.com/watch?v=MmDBvgrYGZs
6. prepare for sleepless nights and for a partner who thinks you are becoming insane
Actually the right order for the above should be 6, 5, 3, 4, 1, 2 8)
Now I deserve a few days off and a beer first of all 8)
-
Addendum to my last post: it is very important that there are no outstanding issues in your device manager. Before plugging in anything run a "check for new devices"; if you get any exclamation mark or yellow sign: fix that first!
I just found out that what played me up the last few days was a missing driver for an Intel USB 3.0 main hub, the bugger was marked as "Unknown Device" :o
To find that out you need to go to device details, hardware id, copy that and Google. Then find the drivers and install.
Maybe worth making a note in Digi Wiki; sorry PeterF I have to find out how to do that but now my candle is burnt..
-
Update on my observations... Powered up the PC this morning with the digispark still plugged into the working port. Later decided to upload a new sketch and got device unknown. Arrrgh...Unplugged the digispark and removed unknown device in the device manager. Reset the PC and all is well again. Somehow having the digispark connected at PC power on caused an issue.
-
Update on my observations... Powered up the PC this morning with the digispark still plugged into the working port. Later decided to upload a new sketch and got device unknown. Arrrgh...Unplugged the digispark and removed unknown device in the device manager. Reset the PC and all is well again. Somehow having the digispark connected at PC power on caused an issue.
Remove the Digispark and renew your device manager: is all ok, no yellow exclamations?
-
Basically removing the physical digispark device, uninstalling the unknown device and restarting the PC got it back to its previously working state. Away now but will see if repeatable when I return.
-
@earckens : No disagreements from me - it if works for you, it works for you! :-P I would suggest that it was more likely just a matter of installing the latest of the correct driver, but your mileage may vary, depending on how your system is set up. And if you already have driver issue... they obviously need to be fixed before pointing the finger at anything else... especially when it is the USB controller driver which funnily enough needs to be working before the USB ports work (100%) properly :-P As far as using one dedicated port, that is the easiest solution. You could also simply just plug it into each port in turn, and install the driver for each device instance, hence it then shouldn't matter which of those ports you plug it into at a later date.
@exeng : stupid question - you unplugged & replugged the digispark when instructed to after having it initially plugged in when you powered up the computer? A digispark not working when a computer is powered up is normal as it gets it's clock from the USB clock. I found that out the hard way when I wanted to do one of these usb volume knobs - if I left the digispark plugged in and powered the computer back up it wouldn't talk to the computer - I had to reset it before it would work. Other than that, that is really peculiar. I don't know if it makes any difference, but I have almost always used the 'digispark programming tool' when working with the digisparks - it basically just allows you to cut the power with a switch do you don't have to constantly unplug and re-plug the digispark... but I wonder if it also means there is a cleaner switch on and off happening. Regardless, I'd be curious to know what happens if you just removed the unknown device in device manager, and then unplugged & replugged the digispark if it happens again.
-
OK, the behavior is repeatable and after thinking about it makes some sense.
Again, The starting point is the Digispark is plugged into a working (dedicated) USB port.
On PC power up, the Digispark receives power (enumeration has not started as the PC is still booting). The Digispark runs it's sketch after the 5 second upload window.
The PC finishes boot and enumeration starts but fails because the Digispark is already running it's sketch.
Device Manager shows the Device Unknown instance.
To answer your question Pete. You have to both remove the unknown device in the device manager then restart the PC. It will continue to fail if you just unplug the Digispark and remove the unknown device in the device manager.
Bottom line, it seems, that the USB port must be empty when the PC starts up.
Finally, this configuration was a direct connect to the PC USB using a cable, not a hub. Don't know if connecting to an external USB hub would hold off power until it (the hub) has enumerated.
I have very limited knowledge of how USB ports / hubs behave. I'm just happy that at least now I have drivers installed, a port that works (albeit dedicated) and some knowledge of how to workaround the power on issue. No more multi plug/unplug required to get it to work.
-
lol... thanks for that exeng... yeah, these 'lil things are pretty temperamental... but as I remember seeing mentioned somewhere... these devices are being pushed to the limits to be able to do this as opposed to a chip that is dedicated to USB stuff, so some flakiness is to be expected unfortunately.
I only know bits and pieces of the the driver stuff in windows, and that is usually due to having had extended conversations with it in which I wished I drank alcohol! :-/ Suffice to say I usually win... but it's never easy! ;-) As far as far as the hub is concerned, it didn't make a scrap of difference to my usb volume knob project - it was plugged into a hub and would never enumerate properly when the computer powered up. If I could have been bothered, i would have made some fancy self-reboot routine or circuit so it could reboot itself if it had powered on with the computer, but I really couldn't be bothered (or now that I think of it... use two digisparks - one to do the reset... one to do the usb... oh... why do I bother!!)
-
lol... thanks for the exeng... yeah, these 'lil things are pretty temperamental...
Hi PeterF, no offence but the fact that the Attiny85 is indeed pushed to the limit in the Digispark does not exonerate "us" from providing as detailed as possible an installation procedure, including anything in any system where it can/may be used that may cause it not to function as required.
If I found out after days and nights of searching that the rootcause was drivers for devices already installed had been missing then I would expect any installation manual at least to mention this. Especially since this device is indeed so finicky about these particular issues. I would bet a case of champagne that this is/has been the issue with lots of other frustrated users. If I buy a car I do not need to be told that the tyre pressure needs to be checked and oil levels too at regular intervals, but there are people who need to be told this information.
So if I would add to my list of six essential items (17/11) I would include the following:
7. Verify -in Device Manager- which device is being added when connecting the Digistump: if that device does not get connected with the Digistump Bootloader driver, then remove all drivers that are at that moment a. not connected (famous listing of grayed out devices when showing "hidden devices") b. connected to the device showing up as present as soon as the Digispark is plugged in
8. Remove again (with drivers) (if present) the Digispark Bootloader driver; reinstall the driver, and make sure it is visible, even grayed out, in the Device manager under "libusb-win32 Usb Vevices"; if it is not, use the right-hand click menu appearing when you click on the uppermost device (your pc) and reinstall using the "add older hardware" option.
9. If all else fails, remove the usb cache: search for infcache.1 and remove (look up in Google for a proper procedure).
And I concur with exeng: make sure your digispark is not usb connected when powering up the pc.
Maybe these items, listed in this discussion thread, could be added to the installation procedure manual, probably in Wiki?
The Digispark is a very useful and versatile board, it would be good to keep this for years to come.
Best regards,
Erik
-
Erik,
And I concur with exeng: make sure your digispark is not usb connected when powering up the pc.
I also discovered that (on WIN 8.1) if the Digispark is connected and running a sketch and the PC goes to or is in sleep, that when is comes back up there is an enumeration that fails. So my evening power down routine is to remove the Digispark and remove all Unknown devices before PC shutdown.
-
I also discovered that (on WIN 8.1) if the Digispark is connected and running a sketch and the PC goes to or is in sleep, that when is comes back up there is an enumeration that fails. So my evening power down routine is to remove the Digispark and remove all Unknown devices before PC shutdown.
Exeng, if I understand correctly you have no means to recover the usb connection to the Digistump after waking up from sleep (and/or hybernation?)? How do/did you proceed then?
Erik
-
Sorry, I left that bit out. Same as before. I have to remove the physical device, remove the unknown device in device manager, then restart the PC if I want to do another upload.
-
Hi PeterF, no offence but the fact that the Attiny85 is indeed pushed to the limit in the Digispark does not exonerate "us" from providing as detailed as possible an installation procedure, including anything in any system where it can/may be used that may cause it not to function as required.
Hey, no offence taken Erik... that is the whole point of discussion forums of this... to document and discuss problems and solutions (and generally have a good time also). All I was getting at was these are nowhere near as reliable re: USB as a dedicated USB interface chip would be, and most of the USB issues are reasonably well documented (both symptom-wise and the technical why-it-happens) when you look up the V-USB/Attiny85 stuff from which the USB stuff for the Digispark originated.
I do wonder though what the root cause of this particular issue is... as I have zero issues with moving the digispark between sockets, and if it doesn't enumerate due to being plugged in when the system was powered up, and just unplugged it and plug it back in again (or flick the switch on the programming adapter off and on again). Maybe the fact that I usually run it through a external USB hub has shielded me from those issues? I also don't need to install multiple sets of drivers, only the one - whatever the latest ones that were distributed on the github release page were. And this is when using Windows 7 (32/64 bit), Win 8.1 (x64) and Win 10 (x64) on two machines, with some linux thrown in the mix as well.
Regardless, the steps you've mentioned do indeed deserve mentioning in the wiki, as they are all perfectly valid troubleshooting steps, and have been shown to work ;)
-
...and most of the USB issues are reasonably well documented (both symptom-wise and the technical why-it-happens) when you look up the V-USB/Attiny85 stuff from which the USB stuff for the Digispark originated.
I do wonder though what the root cause of this particular issue is... as I have zero issues with moving the digispark between sockets, and if it doesn't enumerate due to being plugged in when the system was powered up, and just unplugged it and plug it back in again (or flick the switch on the programming adapter off and on again). Maybe the fact that I usually run it through a external USB hub has shielded me from those issues? I also don't need to install multiple sets of drivers, only the one - whatever the latest ones that were distributed on the github release page were. And this is when using Windows 7 (32/64 bit), Win 8.1 (x64) and Win 10 (x64) on two machines, with some linux thrown in the mix as well.
Hi Peter,
some interesting comments: 1. I was not aware of the V-USB connection, I will do some reading. 2. "enumeration issue": I think there lies part of the root cause: I am using umpteen drivers for all sorts of USB programmers, although for each of them only one and the most recent ;).
Anyway, also then "it" should work without issues but I am not expecting this to be the case without a fight. I am well aware that I am causing part of the trouble myself by using all sorts of USB programmers but again then I want a clear and robust procedure to solve these issues. You name "enumeration", well I think this is spot on. The last few weeks I had on and off again connection problems and "unknown device" listed but each time I could solve the issue by adressing the windows USB enumeration: I succesfully used the steps I described before PLUS this: http://troubleshooter.xyz/fix-usb-device-not-recognized-by-windows/
The main advantage of the ATtiny versus the Pro Mini is its miniature size (almost half) and its amazing low power possibilities.
And to take the route of straight virgin ATtiny85's is economically not interesting.
-
Today after several weeks of other projects I had to reprogram a Digispark. You guess it: UNKNOWN DEVICE >:(
I used my own catalog of fixes (see above): none worked :o I subsequently spent hours trying all kinds of "fixes", no avail >:(, loosing hairs and others turning gray..
Lucky i have a number of spares, tried that as final resort and BINGO.. ;D
I was about to throw the whole bunch on the street, I will wait a bit longer with that final solution.
Erik
-
Addendum: when downloading a program make sure nothing is attached to any pins.
I may be kicking open doors but it is very common to set up your digispark with all the wiring to sensors and outputs attached while trying various program versions.
Undo this wiring before downloading.
-
Yes indeed... forgetting that P3/P4 serve as the USB data pins come back to bite every so often! ;) :o
-
2019 and same here :/