So, I programmed an ATMEGA32u4 and when I connect the device, it doesn't run the code. Instead, it gets recognised as an ATMEGA32u4 chip in Windows device manager.
To get the code running I have to open Atmel FLIP and open USB and then have to press the start application button after which it gets recognised as a HID in device manager and works as intended. I don't know why and what is happening.
The reset is pulled high with a 10k and the HWB is pulled down with a 10k and the chip has the factory bootloader on it.(if this helps)
Pulling down HWB is what you do if you want to start the bootloader built into the ATmega32U4. It sounds like you want to run your own code instead of running the bootloader so you should pull HWB up, or disable the HWBE fuse.
Related
This is new just today. It's been working well for a while now.
When functioning normally, the driver will match on the USB device's
product and vendor IDs, then will load and operate.
It's a USB video adapter so under normal operation, one sees a blurred
image of the desktop until login, then you get a second screen that
works correctly with Display Preferences.
But just today, if the dongle is attached at boot the driver doesn't
load and the USB-attached monitor doesn't show an image.
If I unplug the dongle then plug it back in, it works.
If the dongle is not attached during boot, then plugged in after
reaching the desktop, it works.
If the dongle is attached during boot, and I later use kextutil to
load it, kextutil reports success but it doesn't load.
I speculate it is a problem with matching but don't understand what
could have gone wrong.
It's a signed driver that's now in /Library/Extensions; previously it was unsigned, in /System/Library/Extensions, with System Integrity Protection disabled.
There are two other drivers in the product that are not USB function drivers. They load just fine. All three drivers work together to create a virtual frame buffer then display it.
This could be caused by a bunch of different things. A few suggestions:
Have you verified that ::probe() and ::start() are not being called on your driver class? If they return NULL/false, that will cause behaviour as described.
What's the situation in the IORegistry when your driver has failed to load for a cold-plugged device? Does the nub you match have any client objects?
Have you ruled out a kext cache problem? (E.g. are there any errors when the OS regenerates the kext cache and prelinked kernel?)
Posting your Info.plist might also help - it's possible the problem lies there.
I have an Adafruit Ultimate GPS on a USB serial interface and using the same UWP application can read data just fine on a x86 build on a desktop. When I try a ARM build on the PI3 (remote), everything appears to work, but the serial data read never returns. No timeout, nothing. On the desktop, it starts getting GPS data from the chip right away. I also tried the CustomSerial sample app and am getting the same result. I do have the manifest updated to show serial port access, so don't think that is the problem.
Any ideas would be greatly appreciated. Thanks.
Problem resolved, operator error. Prolific driver not supported, was trying to read data from on-board serial port. Move the GPS sensor to the on-board serial, all is working now. Apologies for the distraction.
I have some old serial based USB touchscreen systems that would be expensive to replace with new hardware.
They are connected in the following manner:
Serial Mouse -> Serial to USB adapter -> Thin Client -> Virtual Machine
Everything works great with one issue. I'm experiencing a driver crash everything user either logs off, shutdown, or reboots. The current workaround has been to disable the serial mouse device before logging off which is a real pain. As long as the device is disabled, everything works great.
I did a lot of research on this issue by taking memory dumps of the crash virtual machines.
It seems like when the user logs off, the USB device is abruptly disconnected and then Windows tries to disable the device gracefully and waits until it is confirmed, thus hanging forever. In assembly it appears to call a .sys file that never returns back.
Is there anything that can be done with an issue like that? Can you change the device shutdown order? Or perhaps tell Windows to not ensure the plug and play device is shutdown? I doubt the vendor would be willing to change their driver.
I wrote a custom solution to this problem.
The application uses the ShutdownBlockReasonCreate API call to block Windows from shutting down. It then listens for reboots or logoffs using the WM_QUERYENDSESSION API call. When it gets this, it disabled the devices and then destroys the shutdown block created.
A real pain but it works
I need to set up USB communication between a Windows 7 host and a Linux device for data transfer. I was able to compile the Linux kernel on the device to include the Gadget Zero driver in the kernel (not as a loadable module - Linux version 3.0.15). My project has some requirements, which also explains why I chose Gadget Zero:
1) On the Windows 7 host, a kernel mode driver must be used to communicate over the USB connection for sending and receiving bulk data. (speed is not important, not a lot of data at once).
2) On the linux device, no requirements on USB side except send and receive data easily over USB link. The data received will eventually be "unmarshalled" to call functions in another kernel module (and those responses packaged and sent back to the host).
3) Multiple linux devices will be connected to the host, so need easy way to enumerate connected devices and communicate with them.
So due to the requirements, I decided against the Gadget Serial. I'm having serious issues sending and receiving data over the virtual COM port in kernel mode (KMDF) in Win 7 host. WinUSB does not seem to want to open my attached device (I'm using KMDF windows USB driver from template in VS2012) Also, the gadget serial driver on the linux side, I cannot find the functions where the data is received and sent. Plus, any received data on the linux device seems to be echoed back to the host for some reason. (and to test this, I wrote a simple user-mode app in Windows, which is a no-no for my project).
Gadget Zero, it appears much simpler on the linux side. I can plug the USB cable to the Win7 host, and I can get the device to appear in the device manager. However, again I am having problems with getting communication going over the link. Gadget Zero has 2 bulk endpoints, so this shouldn't be an issue. Surely, someone has made data communication possible between a Windows host and a linux device using Gadget Zero? With Gadget Zero, it should be easy to enumerate the connected linux devices and communicate with them.
The trick is to keep the Windows side communication in kernel mode. Can someone point me in the right direction perhaps with Gadget Zero, Windows 7 KMDF, and some sample source code? I have a hard time believing no one has done this before because my internet searches don't turn up much. (and mostly user-mode solutions with Gadget Serial).
Thanks!
So you're writing a Win32 driver in which you want to communicate with your linuxed usb? I haven't written much win32 kernel code, but I believe I've seen a huge section in the doc, saying something like "This is how you make usb drivers"... That'd be it. In other words, when in kernel mode you have access to the full kernel usb layer. You don't need an existing driver or whatnot.
On the linux side you can use the serial gadget, in a different run mode. Only the default run mode, registers it self as VCP. There exist a more basic mode:
modprobe g_serial use_acm=0
Give it your own vendor id and you'll be able to attach your very own custom win32 driver. The 'multiple linux devices' will be handled by Windows. (Multiple instances of your driver, will be initiated.)
The echo you're seeing btw, is most likely a terminal feature. (The terminal mode on uarts will echo.) You have to disable it, when connecting. And now that you're at it, you also have to disable the xon/xoff, esc chars etc. (Standard legacy rubbish.)
And another thing. I'm not sure the gadget zero actually sends the data onto the line. It's meant for testing the gadget framework. (I could be mistaken though.)
Anyway, you've prolly solved this issue years ago. I'd be nice to know what you came up with.
I'm using a Limited User account under Windows XP, and I'm having a bit of trouble getting my Adaptoid (the most coveted N64 controller -> USB adapter, because of it's support for sending raw N64 controller commands + the fact that it's been discontinued) to work smoothly: as installed, the included software requires Administrator privileges to load the driver.
Presumably, it is possible to arrange for the driver to be loaded automatically when the Adaptoid is inserted by adding some stuff to the INF file for the driver (wishna1.inf):
the question is, what stuff?
(It would also suit me just as well if the driver could be automatically loaded when anything attempted to open \Device\Wish_NA1, or even to have it automatically loaded at every boot, really, but doing it on insertion seems like the right way.)
Note: I do have access to an administrative account, it's just that I prefer not to have to use it day-to-day.
First of all, let's clarify that a USB device has a Plug & Play driver on Windows 2000 and higher, so services start modes are irrelevant. The driver will have an entry as a "service" in the registry, but its start mode is irrelevant here.
Let's split the problem into two parts:
Installing driver for the device: This requires administrative privileges. This happens when you insert a USB device into a port for the first time. Windows goes over your .INF files to find one that matches your hardware. If the driver is WHQL-certified, it'll load automatically. Otherwise, you'd see the dreaded Add New Hardware wizard. If you're running as admin, a few clicks on Next should be enough to install it. Otherwise, better have that Administrator password ready.
Loading the driver for the device: Once the device is installed, the driver will be loaded each time this device is inserted into this USB port without requiring any additional user intervention. Ever noticed how a USB printer, camera or disk drive load much faster the second time you plug it in? That's because that's just loading, without installing.
From looking at the .INF, it looks valid. Also, it's not WHQL-certified, so you'd have to install it manually.
I'm assuming when you insert the Adaptoid, you get an Add New Hardware wizard. If you point it manually to the installation directory, does the Adaptoid install and function? Does it appear in the Device Manager?
P.S. USB devices which have a serial number are an exception. They're installed once for all USB ports. Those devices are rather uncommon, though.