I am developing on an ARM Mbed board which connects to my Windows laptop over USB. I've just moved to a new Dell laptop running Win 10 [from a Dell laptop running Win 7] and I find that the laptop resets my development board every 15 minutes.
There are two things that will cause the ARM Mbed board to reset:
powering down/up the USB connection
sending "break" via the USB serial driver.
When the reset occurs there is nothing of note in the Windows event logs. I have all of the "allow Windows to power me down" boxes unticked on the USB hubs in System devices and in the Control Panel power management options.
Does anyone have any suggestions on how I (a) debug what's going on or (b) fix/workaround the problem? I've not yet tried connecting via a powered USB hub, will do that next...
I had the same issue using a FRDM-K64F running mBed and communicating over a USB COM port to a Windows 7 Dell machine. The communication would sometimes drop out. As #Rob suggested, uninstalling the Dell Support Assist Agent completely fixed the issue.
Just adding this answer as it was very difficult to find any information using google.
Another note in support of this solution for google...
I have a Dell 5480 running Windows 10, and started using from ST Nucleo boards on it. I've used the exact same boards at work, with no problems. Every 15minutes or so the board was reset.
I tried disabling the Dell Support Assist services but this did not seem to fix the problem.
Removing the programs did make the Nucleo work.
Related
my external monitor stopped working today after restart. I found the computer on during the night. Running win 10 64b on Lenovo U430p.
The monitor worked fine the whole time. I can see windows logo while booting, but then it says no signal. When I uninstalled the video driver it worked (login screen, desktop, res 800*600), until windows installed driver over it. I tried getting newest driver from both Lenovo and Intel, but with no results.
Did anyone experience this issue as well? I read about people having this with new computer but not to happen from the blue and ususally at least disabling the video adapter helped.
Thanks!
Haven't found real solution and it seems to be a problem of Intel graphic cards.
However reverting to most basic driver windows can offer did the trick
Uninstall driver
Rollback driver
Using wushowhide.diagcab utility (https://support.microsoft.com/en-us/kb/3073930) disable updates for all video card drivers
I am developing an application windows 10 on a stationary PC. I also have a tablet windows 10 that once connected to the PC via USB not see debugging (
How to make it accessible?
Ok so I found an article that highlights how to debug a UWP application on a Surface pro using a cable:
Essentially the Visual Studio debugger wants to debug your application via a network, so you are creating a network between your desktop machine and your surface pro.
Below is the guide with the main steps highlighted
https://tomsoderling.github.io/Wired-Debugging-on-Surface/
Hardware Needed
In order to debug over a wired connection, you’ll need a few things:
2 USB to Ethernet dongles. You can find them for pretty cheap on
Amazon.
A length of cat 5 cable to connect the two dongles together.
Connect the dongles together with the ethernet cable, and plug one
dongle into your laptop and the other into the Surface.
Launch the remote debugger program on your surface and configure the following:
No Authentication
Turning this off seems to alleviate a lot of the
hassle of trying to get the debugger to connect to the remote client
app. I debug on a private or wired network and only have the remote
client running when I need to debug, so the lack of security doesn’t
concern me here.
Allow any user to debug
I use this setting because
don’t log into my Windows 10 VM via Parallels so I’ve had an issue
with that. I also use this when my coworker needs to debug on the
Surface.
And then your device should be found in the Auto discover in visual studio
I'm manufacturing a device that connects to my computer using Bluetooth and then a desktop Java app uses the Bluetooth connection to send serial data to the device which is then displayed.
When I try to connect my device to windows 7 it successfully finds and pairs with it creating a Bluetooth link on a COM port. This link can then be used by a serial prompt (used for testing) or my Java application. It works initially however soon after windows drops the connection and the only way to reconnect is to delete the device within devices and printers and then reconnect.
This seems to be a known problem with windows bluetooth so I decieded to use a third party Bluetooth application. I downloaded and tried Toshiba's Bluetooth Stack and it was able to add a Bluetooth device and keep a stable connection which works great however this only works for Toshiba computers without getting a cracked version.
This device is commercial and can't be sold with cracked versions of software. Has anybody experienced the same problems or not in other operating systems and has any solutions of advice as that would be a tremendous help.
This is not a good idea/method to use the COM ports generated by Windows, it's not working fine and not reliable in any scenario ; you should use Bluetooth Sockets instead.
Using Toshiba or Widcomm or BleuSoleil won't help: under Win7, all dongles are now trying to use the Microsoft Stack, not their own implementation.
I have a Metrologic MS1690 Barcode scanner that I'm trying to use with Windows 8.1, I get a Unrecognized Device: Device descriptor request failed error in devices and printers. The scanner gets no power from the computer when it is plugged in because of this. It usually shows up as a usb keyboard in windows 8 and 7, but with 8.1 it does not and I can't find an answer anywhere. Please help! Or even if someone could tell me how to get a generic usb keyboard driver for this thing that may help as well. Thanks.
The scanner gets no power from the computer when it is plugged in
Bit of a guess, but there was a change in Win8.1 that can affect HID devices like this. Such devices are now suspended when no application or service is accessing it. This can cause the device to misbehave if it depends on receiving timely power to operate correctly.
The workaround is to disable Enhanced Power Management for the device. The instructions are pretty elaborately spelled-out in this blog post. At break-neck speed: use Regedit.exe, locate the device in the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Enum\ USB key and set the EnhancedPowerManagementEnabled value to 0.
The "solution" for me has been to add a PCI-E USB card, and use that for the scanner. I went with this one from Rosewill because it uses an NEC chipset which I have heard good things about.
After installing the provided drivers for the PCI-E card, the scanner seems to enumerate consistently (I have only been able to test it for a couple days so far).
According to the person I bought my scanner from, it's an issue with the USB chipset on the motherboard. Some are compatible and some aren't. If I had to do it over again, I would go with an RS232 cable and a power adapter instead of USB. I haven't tested that setup, but if your app needs serial data like mine does, it should be more reliable given that it's not dependent on the vagaries of integrated USB chipsets.
I recently acquired a Bluetooth headset (Philips SHB9100) for my smartphone, but also wanted to use it with my Windows 7 PC, so I bought a cheap USB Bluetooth adapter without noticing it was a v2.0 adapter, while the headset is v2.1 + EDR.
The USB Adapter installed correctly on Windows 7, and I am able to discover my headset, but when they try to pair, an ugly Error 0x80004005 appears, never asking me for a PIN.
After some googling, and founding many people had this pairing problem, I read that the major improvement in Bluetooth v2.1 is SSP, which permits pairing without the need to enter a PIN, and also that Windows 7 chooses the "best pairing mechanism" automatically. And so I started to suspect that this is what's happening:
Windows discovers a SSP capable device.
Windows tries to pair with that device using SSP.
The USB Adapter, being v2.0, is unable to permit pairing with the headset via SSP.
Windows does it's best showing a 0x80004005 error.
I searched for a v2.1 or superior USB Bluetooth Adapter in my city but couldn't find any (I'm from La Plata, Argentina) and even though I think I'll end buying one, I'd like to make this work, or at least know for sure why the devices aren't pairing.
And so my question is (and I swear I did some more googling before asking here):
Can I force Windows to try a legacy pairing with my headset?
Any info on the subject is welcome.
Thanks!
I recently faced a similar issue and after a lot of trial and error together with research, I finally fint a compatible driver. I downloaded a few drivers from the intel site and tried it with each one of them. Finally I was able to fix my issues with the driver below.
https://communities.intel.com/thread/103579
https://downloadcenter.intel.com/download/26191
This link can also help with the issue, worth sharing.
https://superuser.com/questions/471767/bluetooth-headset-pairs-and-appears-in-sound-devices-but-shows-as-disconnected