I have a Lindy IRDA USB bridge attached to my Xperia Neo (Cyanogen Mod 9). I have changed the features to support host mode etc. All is looking fine in the code. I detect the device. I can see the interface and the two endpoints (one in, one out), however as soon as I try to claimInterface it fails, regardless of whether I atempt a force claim or not.
There appears to be no simple way to find out why the claim fails. Though strace gives me a clue as the ioctl call for claim interface fails with a device not found error.
Ignoring the failure gets me only as far as the request which then fails to queue or send.
The questions I have are (I think):-
What exactly is missing that is resulting in the claim failing?
Is there a way around this that ideally would not require root?
Is there a way to override the claim somehow?
OK, so I appear to have fallen into answering my own question here, but I see that a number of people are getting confused over the apparent support for USB Host and the "odd" behaviours that can be observed so hopefully this answer may help some of you out.
I posed 3 questions, I have a definitive answer for 1 & 3 but I am less certain about the other at this stage.
1) What exactly is missing, and why does this result in a bad claim?
The problem is that the device, a lindy IRDA dongle is being detected by the host (my Xperia Neo handset) but that the only configuration that it supports is demanding too much power for the handset to support.
Oddly, this does not prevent either a) the device from being detected and enumerated by the Android libraries or b) from it appearing to be powered (red LED glowing)
There is no report at the time of the failing claimInterface() call from any system libraries, however a dmesg|tail running when the device is attached gave the necessary insight.
dmesg | tail
<3>usb 1-1: device v066f p4200 is not supported
<6>usb 1-1: New USB device found, idVendor=066f, idProduct=4200
<6>usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>usb 1-1: Product: IrDA/USB Bridge
<6>usb 1-1: Manufacturer: Sigmatel Inc
<6>usb 1-1: rejected 1 configuration due to insufficient available bus power
<4>usb 1-1: no configuration chosen from 1 choice
Further investigation showed that this little device was claiming a requirement for 440mA which seems rather a lot but there seems little that can be done about it.
Questions 2 Can anything that does not require root be done to work around this?
It seems not. In theory I could provide external power to the device through the use of a USB Y cable or similar hackery but I don't believe that that would change the underlying problem that the handset refuses the demand. Even with root it is not clear that anything can be done to override the power profile.
Question 3, is there a way to override the claimInterface() failure and force the communications?
This is a blunt no. The device has simply not been created by the kernel so there is nothing there to override in the first place. Which does make it somewhat puzzling as to why the Android libraries still offer it up.
As to Question 2 and power demands...
Most android devices that support Host/OTG that I have run across, will only support a maximum current draw of around 100 mA. Could you force it to work via some kernel source hackery? Likely, but you would run a very real risk of burning up the USB support circuitry in your android device. This is because the Boost converter that such devices use to power the external usb device only physically support that maximum 100 mA current draw.
Could you use a Y-Cable to supply the needed current externally? Yes, I have done this before on a device that had no boost converter, but you would then need to have a workaround in the kernel to tell it that you had such external power, and that it was now okay to power the device up.
Related
This is probably a long shot question, but I try it anyway.
I'm developing hardware using PIC Microcontrollers (MicroChip). Communication is done through a FS USB 2.0 link.
I connect the microcontrollers to a Windows 10 Home edition, version 21H1, build 19043.1826. The processor is an AMD Ryzen 5 3600 6-Core Processor.
First I used the PIC18F45K50, for which everything worked fine from day one. But due to the shortages on the market, I now am experimenting with PIC18F47J53. Both microcontrollers are working fine, as I can (for example) control a MAX7219 controlled display (3 x 7-segment) and also control a bunch of LED's using an STP08CP05TTR. Clock timings seem also ok - I measured it with an oscilloscope.
These 2 microcontrollers are pretty much the same, at least for the core functionality such as USB. The differences that are relevant for the issue I'm reporting here are:
PIC18F45K50 uses internal clock of 8MHz, and has on board correction logic to keep clock synced for HS USB - this is a 5V processor
PIC18F47J53 uses a XTAL of 16MHz, all should be within the USB 2.0 specs - this is a 3.3V processor
I'm using the MPLab X IDE v5.45 with the MCC (MPLab Code Configurator) in which I setup the System Module (to set the correct clock frequencies including the 48MHz for USB) and where I configure the USB.
In both microcontrollers, the setup of the USB is exactly the same. I even checked the 4 files that are automatically generated by MCC, and except for the descriptors (I used different names), all is exactly the same.
When I connect the USB to my PC (same port), then the PIC18F45K50 works perfect. But the PIC18F47J53 gives error code 10.
This does not happen every time. For example, if I try 10 times (connect/disconnect the cable), then I had it 7 times. 1 time the device even didn't appear, and 2 other times I read "The device is working properly.". Although, in the latter case, my software that communicates with my controller isn't working, so there is still something wrong.
Based on the above, the first I would think of is some hardware issue. Although, the strange thing is that things like vendor ID (0x4D8), Product ID (0xA), BCD Device Release (0x100), Serial Number (12345678), etc... seem always to be read out correctly. If there would be a hardware problem, shouldn't I have more random issues with this as well? Or is this data read out in a slower mode than Full Speed (because that could of course explain this)?
Below are screenshots via "Device Manager / Ports (COM & LPT) / my serial device", then selecting the property in the Details.
If I compare the properties from the working microcontroller (PIC18F45K50) with the not working one (PIC18F47J53), it looks like all are exactly the same.
I also tried to compare the D- (CH1) and D+ (CH2) signals between the 2 microcontrollers with my oscilloscope. My USB knowledge is not detailed enough to interpret the signals, but what I can tell is that both look exactly the same to me, both timing wise and voltage level wise. Be aware that the CH2 signal on the PIC18F47J53 (D+), the second screenshot, is clipping in the picture below, but I measured it later and it shows the same voltage level as for the PIC18F45K50.
Does anybody here a single clue where I should look at in the first place? The good news is that I have a working and not working version, so I can start debugging step by step and compare. But some hints as where to start would be appreciated.
EDIT 24JUL2022
I did the measurement with my oscilloscope again. Now I soldered 2 wires to the USB port to be able to easily attach my probes. This time, both D- and D+ signals have a Vpp of about 3.3V. I put some cursors which also shows a pulse-width of about 84ns, which correlates with the USB HS frequency of 12MHz (should be 83.33ns).
I found the issue. The Vusb on my PIC18F47J53 had a bad (or was even not) connected. I gave it another touch of my soldering iron, and bingo! Now the "error 10" has disappeared completely, and each time I connect/disconnect it gives "This device is working properly.", and error 10 never appears. I now also see a continues signal on my oscilloscope - not one that is disappearing after a while. And I could send/receive already some commands.
I work with an embedded device that has a USB host port. I would like to connect an iPhone to it and communicate via USB. I have done development on this and ported the functionality to connect to usbmux on the iPhone and have successful communication, however there is another problem.
All development was done with the iPhone connected to a powered USB hub that was connected to my device, as soon as I connected it directly, after enumeration it starts to drain the battery of my embedded device and causes a tension (voltage) drop that causes my device to turn off.
I know that after enumeration usb devices can draw up to 500 mA from the usb port, but I was wondering if there was a way to limit that to 100 mA (while still having the iPhone registered).
I found various questions regarding controlling voltage on the data pins or vcc from the usb port and I understand that's not possible, I'm looking for a software solution (although hardware solutions are welcome).
tl;dr: Is there a way to supply the iPhone with less than 500 mA after enumeration? Could I do this in software? Or do I need a hardware solution? I don't want to turn the port on/off, just limit the power draw of the iPhone.
NOTE: I am using Windows CE 6.0, if it is something that can only be done by modifying the drivers, or having direct access, there is no problem.
P.S. also, if there is a way to do this in *nix (or some other open source OS) that I could look at the source code and port it to Windows CE please let me know.
When a device shares its available configurations (see USB chapter 9), it specifies how much power it requires for each configuration. The host should look at all the available configurations and choose which one it wants.
In practice, however, these things don't work so smoothly.
The last time I looked at this, Windows always chose the first configuration. MacOS always chose the lowest power configuration (or highest, I can't remember). I never looked at WinCE or Linux.
If you're writing/modifying the driver, you can set your own rules for which configuration to choose, including looking for one that's 'self powered'. The iPhone, however, might only have one descriptor that always requests 500mA, bus powered. If so, then you're pretty much screwed since there's no way to let the iPhone know it's not OK to draw power.
That being said, I believe all the iPhone accessories are actually USB host (as opposed to USB device), and given that they don't always supply power, the iPhone must be capable of enumerating self powered.
I like the answer by Russ Schultz but I want to add another one:
No.
The descriptor of the peripheral device, iPhone in this case contains bMaxPower. If you enumerate this device, you also accept the power demand. It is not possible to only supply less, lets say 300 mA, if you already enumerated the device with the 500 mA desriptor. If this is what you wanted.
If the device provides multiple configurations, you are as mentioned by Russ free to write a driver which selects the configuration with less power. Hopefully, the device will then only consume the granted power.
Many peripheral devices just don't care. Most devices only provide one configuration with 500 mA. And there are a lot of devices which just consume more than they say ...
I had a look at this and this but no one sounded particularly sure of their ideas and I'm kind of after a different thing anyway. I want to hook my usb power cables (red and black) up to my phone so I don't have to use a battery (the battery is dead anyway and this is just an experiment). The problem is that USB standards ensure that a minimum of 4.35V is supplied, when I only want 3.7V. Does anyone know for sure that you can or cannot regulate power output programmatically? Some other queries I have are: What kind of power does the sleep mode provide? And what would I need to code something in to play with this, C++?
No, you won't find a computer that allows you to set this voltage in software. It would break the USB specification.
You can get 150mA by default, and 500mA if your USB device negotiates it with the computer (requiring a little bit of logic in the device). Multiply by 5V to get the provided power.
A bit more info on the answer from Pascal:
The normal operation (Non-Configured mode) is 100mA
In theory, the operating system should check the MaxPower value of the device's configuration descriptor to decide if to allow it to draw more than 100mA.
In practice, PCs do not do it (and have no way to control it). So you can try taking 500mA.
(Of course connecting a bus powered hub and linking more then one 500mA device, should, not work.)
If the device is not actively used, the OS may (and should) suspend it. When suspended the power is limited to 1-0.5mA (Again, in theory, since it can not be controlled by software).
I have a device that came with an AC power adapter where the connector is a mini USB plug. The device however doesn't seem to power itself from a computer's USB port (using a standard USB-mini USB cable) unless a specific driver is installed. The driver is only available for Windows. I would like to charge the device from USB plugs on different platforms.
My question is: why isn't power getting to the device without the driver? Is a driver always required for a USB port to start giving power? Or is it this device that's specifically made not to take a charge unless some software routine triggers it to do so?
I guess my question can be summarized as: Is power not present on the USB cable or is it present but the device ignoring it. If the answer is the former, I'll be trying to figure out how to write software that will enable the voltage to always be present.
Thanks
Why isn't power getting to the device without the driver?
USB ports are always powered when the computer is on and the USB control software hasn't detected current overdraw.
Is a driver always required for a USB port to start giving power?
No, the USB port is always required to start off providing power to the device, otherwise the device could never initiate a connection.
Or is it this device that's specifically made not to take a charge unless some software routine triggers it to do so?
This can be complex. To meet the USB spec a device cannot pull more than a few mA until it's registered with the computer.
However, nearly every computer allows the USB port to pull the full 500mA (and more) before it'll shut the power off.
The device you're charging is being nice by not pulling any significant power until the computer gives permission.
Writing software won't help, the device has to register with the USB bus, which will best be done with the driver.
However, the plug in charger doesn't do that. It likely has shorted the two data lines of the USB plug together, which signals the USB device that it's not connected to a computer and can pull the full 500mA without waiting.
Take a USB extension cable, cut off the jacket, and short the data lines (green and yellow, sometimes) together on the end going to the USB device, and leave them cut without touching anything on the end going to the PC, and leave the read and black power wires connected through.
It might work. If not, take the wall charger apart and find out what it's doing with each of the four USB wires, and see if you can duplicate that.
This might be helpful if you are targeting a linux system.
This seems to be platform-specific. In Linux, USB ports are always energized, while on Windows they don't. Thumbdrives with LEDs turn off when unmounted in windows, but in Linux they stay lit. My cellphone's manual says that it can't be charged by a PC, but I regularly do on my linux machine, I guess that's because they don't have a driver and windows won't power up without one.
Have you tried plugging it into a 'dumb' USB port - like the one on a car charger? Those ports are pure power and don't create a USB network. I think.
Unless you have the hardware specs from the manufacturer, I think you are out of luck. You could try reverse engineering the driver to see what it does, but I'd expect it would be cheaper and easier just to buy one with cross platform drivers or charges without the driver.
I have been tasked to write a device driver for an embedded device which will communicate with the micro controller via the SPI interface. Eventually, the USB interface will be used to download updated code externally and used during the verification phase.
My question is, does anyone know of a good reference design or documentation or online tutorial which covers the implementation/design of the USB protocol stack/device driver within an embedded system? I am just starting out and reading through the 650 page USB v2.0 spec is a little daunting at the moment.
Just as a FYI, the micro controller that I am using is a Freescale 9S12.
Mark
Based upon goldenmean's (-AD) comments I wanted to add the following info:
1) The embedded device uses a custom executive and makes no use of a COTS or RTOS.
2) The device will use interrupts to indicate data is ready to be retrieved from the device.
3) I have read through some of the docs regarding Linux, but since I am not at all familiar with Linux it isn't very helpful at the moment (though I am hoping it will be very quickly).
4) The design approach, for now at least, it to write a device driver for the USB device then a USB protocol layer (I/O) would reside on top of the device driver to interpret the data. I would assume this would be the best approach, though I could be wrong.
Edit - A year later
I just wanted to share a few items before they vanish from my mind in case I never work on a USB device again. I ran into a few obstacles when developing code and getting it up and running for the first.
The first problem I ran into was that when the USB device was connected to the Host (Windows in my case) was the host issues a Reset request. The USB device would reset and clear the interrupt enable flags. I didn't read the literature enough to know this was happening, thus I was never receiving the Set-Up Request Interrupt. It took me quite a while to figure this out.
The second problem I ran into was not handling the Set-Up Request for Set_Configuration properly. I was handling it, but I was not processing the request correctly in that the USB device was not sending an ACK when this Set-Up Request came in. I eventually found this out by using a hardware USB protocol analyzer.
There were other issues that I ran into, but these were the two biggest ones that took me quite a while to figure out. The other issue I had to worry about is big-endian and little-endian, Freescale 9S12 vs USB data format (Intel), respectively.
I ended up building the USB device driver similar to UART device drivers I had done in the past. I have posted the code to this at the following URL.
http://lordhog.wordpress.com/2010/12/13/usb-drive
I tend to use structures a lot, so people may not like them since they are not as portal as using #defines (e.g., MAX3420_SETUP_DATA_AVAIL_INT_REQR 0x20), but I like them since it makes the code more readable for me. If anyone has questions regarding it please feel free to e-mail and I can try to give some insight to it. The book "USB Complete: The Developer's Guide" was helpful, so long as you knew what areas to concentrate on. This was a simple application and only used low-speed USB.
While writing a device driver for any interface (USB, Parallel port, etc...) the code needed to be developed would depend upon whether there is any Operating System(OS), RTOS running on that Processor/Micro controller.
e.g. if thats going to run say WinCE - It will have its own Driver development Kit , and steps to be followed in the device driver development. Same for any other OS like Linux, symbian.
If its going to be a plain firmware code(No OS) which is going to control the processor/microcontroller, then it's a different situation altogether.
So based on either of the above situation u are in, one needs to read & understand:-
1.) The Hardware Specification of the processor/micro controller development board - Register files, ports, memory layout, etc.
2.) USB spec
3.) Couple of pointers i found quickly. Google shud be ur friend!
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ - Linux USB device driver
http://www.microsoft.com/technet/archive/wce/support/usbce.mspx
-AD
I've used an earlier edition of USB Complete by Jan Axelson. Indeed very complete.
From the editorial review:
Now in its fourth edition, this developer's guide to the Universal Serial Bus (USB) interface covers all aspects of project development, such as hardware design, device firmware, and host application software.
I'm curious, why did you pick the 9S12? I used it at a previous job, and was not pleased.
It had lousy gcc support so we used Metrowerks
which may have been okay for C, but often generated buggy C++
had a lousy IDE with binary project files!
The 9s12 was also slow, a lot of instructions executed in 5 cycles.
Not very power efficient, either.
no barrel shifter, made operations that are common in embedded code slow
not that cheap.
About the only thing I dislike more is an 8051. I'm using an ARM CortexM3 at my current job, it's better than a 9S12 in every way (faster clock, more work done per clock, less power consumption, cheaper, good gcc support, 32-bit vs. 16-bit).
I don't know which hardware you're planning to use but assuming that's flexible, STMicro offers a line of microcontrollers with USB/SPI support and a library of C-code that can be used with their parts. -- I've used their ARM7 series micros for years with great success.
Here is an excellent site maintained by Jonathan Valvano, a professor at the University of Texas. He teaches four courses over there (three undergraduate, one graduate), all are about using a 9S12 microcontroller. His site contains all the lecture notes, lab manuals, and more importantly, starter files, that he uses for all his classes.
The website looks like it's from the 90's, but just dig around a bit and you should find everything you need.
users.ece.utexas.edu/~valvano/
Consider AVR for your next MCU project because of it's wonderful LUFA and V-USB libraries.
I'm working on a project using the Atmel V71. The processor is very powerful and among lot's of high end connectivity offered on chip is a USB engine that will do device or host modes for 480 Mhz or 48Mhz (not USB 3.0). The tools are free and come with a number of host and device USB example projects with all the USB stack code right there. It supports 10 end points and all the transfers are done via DMA so you have most of the processor horsepower available for other tasks. The Atmel USB stack works without needing an RTOS