From: Lark, N. (S. G. UK) <nat...@se...> - 2012-02-27 16:52:11
|
We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. Any help would be most appreciated :) --snip-------------------------- ..then altered the file: /tmp/work/overo-angstrom-linux-gnueabi/linux-omap3-2.6.32-r51/git/drivers/usb/host/ehci.h by changing the following line from: /* REVISIT charge pump on TWL4030 can supply up to * 100 mA ... but this value is board-specific, like * "mode", and should be passed to usb_musb_init(). */ .power = 50, /* up to 100 mA */ to: /* REVISIT charge pump on TWL4030 can supply up to * 100 mA ... but this value is board-specific, like * "mode", and should be passed to usb_musb_init(). */ .power = 250, /* up to 500 mA */ Rebuilding the kernel, I can confirm that the gumstix now accepts connections from high - current devices, hopefully including devices such as your camera :) --snip-------------------- SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** |
From: Alexander T. <ale...@es...> - 2012-02-28 09:51:30
|
On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: > We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com |
From: Mark Z. <mar...@oc...> - 2012-02-28 13:20:03
|
Hi Alexander, > echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue > This disables the power limit enforcing. Very cool! We ended up reflashing the USB declarations so our "actual" 400mA device declared itself to be a safe and harmless 80mA device (since we were providing external power). Your solution is much more elegant :-) -Mark On Feb 28, 2012, at 4:51 AM, Alexander Thomas wrote: > On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) > <nat...@se...> wrote: >> We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. >> >> This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. >> >> Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. >> >> Any help would be most appreciated :) > > > I had this exact same problem and found a solution for more recent > kernels. After plugging in the device, run the following command: > echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue > This disables the power limit enforcing. You may still get a warning > in the system log, but the device should work. > This has to be repeated every time the Overo is rebooted or the device > is plugged in. > > Of course you should never run this command when a device that can > draw more than 100mA is connected to the OTG port with a non-spliced > cable. > > -- > Alexander Thomas > Research Engineer > > eSATURNUS NV > T +32 16 40 12 82 > M +32 477 51 63 62 > http://www.esaturnus.com > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users ******************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify the sender immediately and then delete this e-mail. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard copy version. ******************************************************** |
From: Nathan121 <nat...@se...> - 2012-02-28 20:44:30
|
Alexander, thanks very much for this reply. You solved the problem \o/ Alexander Thomas-8 wrote: > > On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) > <nat...@se...> wrote: >> We are attempting to remotely power a USB device by splicing into the gnd >> and 5V power lines and providing an alternative supply from that provided >> by the Overo OTG USB port. >> >> This issue surrounding how the USB device presents itself and why the >> device will still be rejected even though it is externally powered is >> understood by us. What we cant do is find a solution to bypassing the >> power check all together. The archives suggest some approaches and code >> changes to the kernel back in 2010, however a search of our kernel source >> code (3.0.0.) suggest this may not be relevant any longer. >> >> Chris cotton provided this solution in an earlier discussion, May 10, >> 2010, however we could find no such code to make the change. >> >> Any help would be most appreciated :) > > > I had this exact same problem and found a solution for more recent > kernels. After plugging in the device, run the following command: > echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue > This disables the power limit enforcing. You may still get a warning > in the system log, but the device should work. > This has to be repeated every time the Overo is rebooted or the device > is plugged in. > > Of course you should never run this command when a device that can > draw more than 100mA is connected to the OTG port with a non-spliced > cable. > > -- > Alexander Thomas > Research Engineer > > eSATURNUS NV > T +32 16 40 12 82 > M +32 477 51 63 62 > http://www.esaturnus.com > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Alternative-OTG-USB-power-tp33401074p33409614.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Mark S. <mar...@tu...> - 2013-01-29 17:12:45
|
Hello Alexander, I'm trying to get a webcam to work the same way you did it. I spliced a USB cable and connected the power lines to a 5 V source. However, when I connect the camera there is no handshaking taking place anymore. The data lines are intact and the power lines going to the gumstix are dead ends. Could that be the problem? Do you have any idea why this is and what I could do with the dead ends to fake a connection if that's what's missing for the handshaking? Thanks a lot in advance. Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst On Feb 28, 2012, at 10:51 AM, Alexander Thomas <ale...@es...> wrote: On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: > We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Mark S. <mar...@tu...> - 2013-01-29 17:17:43
|
Update: I now connected the GND cables and got the devices to do the handshaking. The camera gets rejected as expected but when I use the command you suggested changing the bCinfiguationValue I get. "usb 1-1: new config #1 exceeds power limit by 400mA". Did you get the same output because the camera still does not work? On Jan 29, 2013, at 5:29 PM, Mark Stamer <mar...@tu...> wrote: Hello Alexander, I'm trying to get a webcam to work the same way you did it. I spliced a USB cable and connected the power lines to a 5 V source. However, when I connect the camera there is no handshaking taking place anymore. The data lines are intact and the power lines going to the gumstix are dead ends. Could that be the problem? Do you have any idea why this is and what I could do with the dead ends to fake a connection if that's what's missing for the handshaking? Thanks a lot in advance. Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst On Feb 28, 2012, at 10:51 AM, Alexander Thomas <ale...@es...> wrote: On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: > We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Alexander T. <ale...@es...> - 2013-01-30 09:29:54
|
Hi Mark, It has been a while since I did this and it was on an old kernel. We're no longer using this setup so I cannot tell how it behaves on more recent kernels that may have more strict power management. I believe the “exceeds” warning is normal however. If it doesn't work with Greg's suggestion, you could try an older kernel. If everything fails, you may have to resort to a powered USB hub... Alexander On Tue, Jan 29, 2013 at 6:17 PM, Mark Stamer <mar...@tu...> wrote: > Update: I now connected the GND cables and got the devices to do the > handshaking. The camera gets rejected as expected but when I use the > command you suggested changing the bCinfiguationValue I get. "usb 1-1: new > config #1 exceeds power limit by 400mA". Did you get the same output > because the camera still does not work? > > > On Jan 29, 2013, at 5:29 PM, Mark Stamer <mar...@tu...> wrote: > > Hello Alexander, > > I'm trying to get a webcam to work the same way you did it. I spliced a > USB cable and connected the power lines to a 5 V source. However, when I > connect the camera there is no handshaking taking place anymore. The data > lines are intact and the power lines going to the gumstix are dead ends. > Could that be the problem? Do you have any idea why this is and what I > could do with the dead ends to fake a connection if that's what's missing > for the handshaking? > > Thanks a lot in advance. > > > Dipl.-Ing. Mark Stamer > Technische Universität Hamburg-Harburg > Institut für Mikrosystemtechnik (E-7) > Eißendorfer Str. 42 > 21073 Hamburg > Germany > > Tel.: +49 (0)40 42878 2402 > Fax: +49 (0)40 42878 2396 > Email: mar...@tu... > http://www.tu-harburg.de/mst > > On Feb 28, 2012, at 10:51 AM, Alexander Thomas < > ale...@es...> wrote: > > On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) > <nat...@se...> wrote: > > We are attempting to remotely power a USB device by splicing into the gnd > and 5V power lines and providing an alternative supply from that provided > by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the > device will still be rejected even though it is externally powered is > understood by us. What we cant do is find a solution to bypassing the > power check all together. The archives suggest some approaches and code > changes to the kernel back in 2010, however a search of our kernel source > code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, > 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) > > > > I had this exact same problem and found a solution for more recent > kernels. After plugging in the device, run the following command: > echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue > This disables the power limit enforcing. You may still get a warning > in the system log, but the device should work. > This has to be repeated every time the Overo is rebooted or the device > is plugged in. > > Of course you should never run this command when a device that can > draw more than 100mA is connected to the OTG port with a non-spliced > cable. > > -- > Alexander Thomas > Research Engineer > > eSATURNUS NV > T +32 16 40 12 82 > M +32 477 51 63 62 > http://www.esaturnus.com > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Alexander Thomas Research Engineer eSATURNUS T. +32 16 40 12 82 www.esaturnus.com |
From: Greg K. <gk...@ya...> - 2013-01-29 17:22:45
|
Mark, You might try toggling OVERO_GPIO_USBH_CPEN 168 or OVERO_GPIO_USBH_NRESET 183 In userspace, after boot. In a similar splice situation, toggling 168 solved a similar problem for me. I think at boot there's some timing problem related to the power. Greg ________________________________ From: Mark Stamer <mar...@tu...> To: General mailing list for gumstix users. <gum...@li...> Sent: Tuesday, January 29, 2013 8:29 AM Subject: Re: [Gumstix-users] Alternative OTG USB power Hello Alexander, I'm trying to get a webcam to work the same way you did it. I spliced a USB cable and connected the power lines to a 5 V source. However, when I connect the camera there is no handshaking taking place anymore. The data lines are intact and the power lines going to the gumstix are dead ends. Could that be the problem? Do you have any idea why this is and what I could do with the dead ends to fake a connection if that's what's missing for the handshaking? Thanks a lot in advance. Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst On Feb 28, 2012, at 10:51 AM, Alexander Thomas <ale...@es...> wrote: On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > >This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > >Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > >Any help would be most appreciated :) > I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Mark S. <mar...@tu...> - 2013-01-30 16:47:27
|
Hey, thanks for you quick reply. Pin 183 doesn't exist and pin 168 was already set to 1 but even toggling it off and on again didn't work. I'm using Kernel 2.6.34. Do you consider this an "old" Kernel? Unfortunately a powered USB Hub is not an option for my application even though I have one where the camera works. On Jan 29, 2013, at 6:22 PM, Greg Kogut <gk...@ya...> wrote: Mark, You might try toggling OVERO_GPIO_USBH_CPEN 168 or OVERO_GPIO_USBH_NRESET 183 In userspace, after boot. In a similar splice situation, toggling 168 solved a similar problem for me. I think at boot there's some timing problem related to the power. Greg From: Mark Stamer <mar...@tu...> To: General mailing list for gumstix users. <gum...@li...> Sent: Tuesday, January 29, 2013 8:29 AM Subject: Re: [Gumstix-users] Alternative OTG USB power Hello Alexander, I'm trying to get a webcam to work the same way you did it. I spliced a USB cable and connected the power lines to a 5 V source. However, when I connect the camera there is no handshaking taking place anymore. The data lines are intact and the power lines going to the gumstix are dead ends. Could that be the problem? Do you have any idea why this is and what I could do with the dead ends to fake a connection if that's what's missing for the handshaking? Thanks a lot in advance. Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst On Feb 28, 2012, at 10:51 AM, Alexander Thomas <ale...@es...> wrote: On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: > We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d_______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst |
From: Brent <br...@ro...> - 2013-01-30 19:52:08
|
I don't have any solutions, but I came across this and have some details fresh in my mind I figured I'd share. GPIO 183 exists, it is the data line for I2C bus 2. Not sure what it's actually used for, but it doesn't seem to come out of the 70 pin connections (off the COM). GPIO 168 runs through a buffer and enables the current limiting IC on the USB host port. Set it low and Vbus on the host port will lose power. Set the pin high again, and current limited 5V should return. - Brent -- View this message in context: http://gumstix.8.n6.nabble.com/Alternative-OTG-USB-power-tp4515407p4966659.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <as...@gu...> - 2013-01-30 20:14:02
|
On Wed, Jan 30, 2013 at 11:35 AM, Brent <br...@ro...> wrote: > GPIO 183 exists, it is the data line for I2C bus 2. Not sure what it's > actually used for, but it doesn't seem to come out of the 70 pin connections > (off the COM). GPIO183 is the reset line for the USB Host PHY on the COM. This is the 'RESETB' line in data sheet for the USB3320. --Ash |
From: Alexander T. <ale...@es...> - 2013-01-31 09:36:02
|
Hi Mark, I have dug into my old notes and it seems I was using 2.6.35. Some other points on the checklist: * Make sure that the plug that connects to the USB OTG port has its 'ID' pin connected to ground to let the port know that it should work as a host. * Make sure that the cable is plugged into the USB OTG port before booting. * The `echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue` command must be run when the device has already been plugged in, not before. On Wed, Jan 30, 2013 at 5:47 PM, Mark Stamer <mar...@tu...> wrote: > Hey, > > thanks for you quick reply. Pin 183 doesn't exist and pin 168 was already > set to 1 but even toggling it off and on again didn't work. I'm using > Kernel 2.6.34. Do you consider this an "old" Kernel? > > Unfortunately a powered USB Hub is not an option for my application even > though I have one where the camera works. > > > On Jan 29, 2013, at 6:22 PM, Greg Kogut <gk...@ya...> wrote: > > Mark, > > You might try toggling > > OVERO_GPIO_USBH_CPEN <http://lxr.free-electrons.com/ident?v=2.6.33;i=OVERO_GPIO_USBH_CPEN> 168 <http://lxr.free-electrons.com/source/arch/arm/mach-omap2/board-overo.c?v=2.6.33#L58> > > or > > OVERO_GPIO_USBH_NRESET <http://lxr.free-electrons.com/ident?v=2.6.33;i=OVERO_GPIO_USBH_NRESET> 183 <http://lxr.free-electrons.com/source/arch/arm/mach-omap2/board-overo.c?v=2.6.33#L59> > In userspace, after boot. In a similar splice situation, toggling 168 solved a similar problem for me. > I think at boot there's some timing problem related to the power. > > Greg > > > ------------------------------ > *From:* Mark Stamer <mar...@tu...> > *To:* General mailing list for gumstix users. < > gum...@li...> > *Sent:* Tuesday, January 29, 2013 8:29 AM > *Subject:* Re: [Gumstix-users] Alternative OTG USB power > > Hello Alexander, > > I'm trying to get a webcam to work the same way you did it. I spliced a > USB cable and connected the power lines to a 5 V source. However, when I > connect the camera there is no handshaking taking place anymore. The data > lines are intact and the power lines going to the gumstix are dead ends. > Could that be the problem? Do you have any idea why this is and what I > could do with the dead ends to fake a connection if that's what's missing > for the handshaking? > > Thanks a lot in advance. > > > Dipl.-Ing. Mark Stamer > Technische Universität Hamburg-Harburg > Institut für Mikrosystemtechnik (E-7) > Eißendorfer Str. 42 > 21073 Hamburg > Germany > > Tel.: +49 (0)40 42878 2402 > Fax: +49 (0)40 42878 2396 > Email: mar...@tu... > http://www.tu-harburg.de/mst > > On Feb 28, 2012, at 10:51 AM, Alexander Thomas < > ale...@es...> wrote: > > On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) > <nat...@se...> wrote: > > We are attempting to remotely power a USB device by splicing into the gnd > and 5V power lines and providing an alternative supply from that provided > by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the > device will still be rejected even though it is externally powered is > understood by us. What we cant do is find a solution to bypassing the > power check all together. The archives suggest some approaches and code > changes to the kernel back in 2010, however a search of our kernel source > code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, > 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) > > > > I had this exact same problem and found a solution for more recent > kernels. After plugging in the device, run the following command: > echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue > This disables the power limit enforcing. You may still get a warning > in the system log, but the device should work. > This has to be repeated every time the Overo is rebooted or the device > is plugged in. > > Of course you should never run this command when a device that can > draw more than 100mA is connected to the OTG port with a non-spliced > cable. > > -- > Alexander Thomas > Research Engineer > > eSATURNUS NV > T +32 16 40 12 82 > M +32 477 51 63 62 > http://www.esaturnus.com > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > > http://p.sf.net/sfu/learnnow-d2d_______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > Dipl.-Ing. Mark Stamer > Technische Universität Hamburg-Harburg > Institut für Mikrosystemtechnik (E-7) > Eißendorfer Str. 42 > 21073 Hamburg > Germany > > Tel.: +49 (0)40 42878 2402 > Fax: +49 (0)40 42878 2396 > Email: mar...@tu... > http://www.tu-harburg.de/mst > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- Alexander Thomas Research Engineer eSATURNUS T. +32 16 40 12 82 www.esaturnus.com |
From: Mark S. <mar...@tu...> - 2013-01-31 14:20:13
|
Alexander, I tried what you said in the exact order but it still won't work. The "ID" pin should be grounded as I connected the ground from both sides. I'm thinking of connecting the 5 V from the battery to the USB OTG port side even though I have a little doubt this could damage the board. I'll let you know if that did the trick. On Jan 31, 2013, at 10:35 AM, Alexander Thomas <ale...@es...> wrote: Hi Mark, I have dug into my old notes and it seems I was using 2.6.35. Some other points on the checklist: * Make sure that the plug that connects to the USB OTG port has its 'ID' pin connected to ground to let the port know that it should work as a host. * Make sure that the cable is plugged into the USB OTG port before booting. * The `echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue` command must be run when the device has already been plugged in, not before. On Wed, Jan 30, 2013 at 5:47 PM, Mark Stamer <mar...@tu...> wrote: Hey, thanks for you quick reply. Pin 183 doesn't exist and pin 168 was already set to 1 but even toggling it off and on again didn't work. I'm using Kernel 2.6.34. Do you consider this an "old" Kernel? Unfortunately a powered USB Hub is not an option for my application even though I have one where the camera works. On Jan 29, 2013, at 6:22 PM, Greg Kogut <gk...@ya...> wrote: Mark, You might try toggling OVERO_GPIO_USBH_CPEN 168 or OVERO_GPIO_USBH_NRESET 183 In userspace, after boot. In a similar splice situation, toggling 168 solved a similar problem for me. I think at boot there's some timing problem related to the power. Greg From: Mark Stamer <mar...@tu...> To: General mailing list for gumstix users. <gum...@li...> Sent: Tuesday, January 29, 2013 8:29 AM Subject: Re: [Gumstix-users] Alternative OTG USB power Hello Alexander, I'm trying to get a webcam to work the same way you did it. I spliced a USB cable and connected the power lines to a 5 V source. However, when I connect the camera there is no handshaking taking place anymore. The data lines are intact and the power lines going to the gumstix are dead ends. Could that be the problem? Do you have any idea why this is and what I could do with the dead ends to fake a connection if that's what's missing for the handshaking? Thanks a lot in advance. Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst On Feb 28, 2012, at 10:51 AM, Alexander Thomas <ale...@es...> wrote: On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: > We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d_______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Alexander Thomas Research Engineer eSATURNUS T. +32 16 40 12 82 www.esaturnus.com ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Mark S. <mar...@tu...> - 2013-02-08 11:37:20
|
Hello everyone, I finally got the uEye USB camera working on the OTG! The suggestions to disable the power check where perfectly fine. However, the uEye daemon "ueyeusbdrc" had to be restart afterwards in order for the camera to work. FYI here the two simple steps in detail: 1. echo > 1 /sys/bus/usb/devices/usb1/1-1/bConfigurationValue 2. /etc/init.d/ueyeusbdrc restart Thanks for your help! On Jan 31, 2013, at 3:20 PM, Mark Stamer <mar...@tu...> wrote: Alexander, I tried what you said in the exact order but it still won't work. The "ID" pin should be grounded as I connected the ground from both sides. I'm thinking of connecting the 5 V from the battery to the USB OTG port side even though I have a little doubt this could damage the board. I'll let you know if that did the trick. On Jan 31, 2013, at 10:35 AM, Alexander Thomas <ale...@es...> wrote: Hi Mark, I have dug into my old notes and it seems I was using 2.6.35. Some other points on the checklist: * Make sure that the plug that connects to the USB OTG port has its 'ID' pin connected to ground to let the port know that it should work as a host. * Make sure that the cable is plugged into the USB OTG port before booting. * The `echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue` command must be run when the device has already been plugged in, not before. On Wed, Jan 30, 2013 at 5:47 PM, Mark Stamer <mar...@tu...> wrote: Hey, thanks for you quick reply. Pin 183 doesn't exist and pin 168 was already set to 1 but even toggling it off and on again didn't work. I'm using Kernel 2.6.34. Do you consider this an "old" Kernel? Unfortunately a powered USB Hub is not an option for my application even though I have one where the camera works. On Jan 29, 2013, at 6:22 PM, Greg Kogut <gk...@ya...> wrote: Mark, You might try toggling OVERO_GPIO_USBH_CPEN 168 or OVERO_GPIO_USBH_NRESET 183 In userspace, after boot. In a similar splice situation, toggling 168 solved a similar problem for me. I think at boot there's some timing problem related to the power. Greg From: Mark Stamer <mar...@tu...> To: General mailing list for gumstix users. <gum...@li...> Sent: Tuesday, January 29, 2013 8:29 AM Subject: Re: [Gumstix-users] Alternative OTG USB power Hello Alexander, I'm trying to get a webcam to work the same way you did it. I spliced a USB cable and connected the power lines to a 5 V source. However, when I connect the camera there is no handshaking taking place anymore. The data lines are intact and the power lines going to the gumstix are dead ends. Could that be the problem? Do you have any idea why this is and what I could do with the dead ends to fake a connection if that's what's missing for the handshaking? Thanks a lot in advance. Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst On Feb 28, 2012, at 10:51 AM, Alexander Thomas <ale...@es...> wrote: On Mon, Feb 27, 2012 at 5:51 PM, Lark, Nathaniel (SELEX GALILEO, UK) <nat...@se...> wrote: > We are attempting to remotely power a USB device by splicing into the gnd and 5V power lines and providing an alternative supply from that provided by the Overo OTG USB port. > > This issue surrounding how the USB device presents itself and why the device will still be rejected even though it is externally powered is understood by us. What we cant do is find a solution to bypassing the power check all together. The archives suggest some approaches and code changes to the kernel back in 2010, however a search of our kernel source code (3.0.0.) suggest this may not be relevant any longer. > > Chris cotton provided this solution in an earlier discussion, May 10, 2010, however we could find no such code to make the change. > > Any help would be most appreciated :) I had this exact same problem and found a solution for more recent kernels. After plugging in the device, run the following command: echo -n 1 > /sys/devices/platform/musb_hdrc/usb1/1-1/bConfigurationValue This disables the power limit enforcing. You may still get a warning in the system log, but the device should work. This has to be repeated every time the Overo is rebooted or the device is plugged in. Of course you should never run this command when a device that can draw more than 100mA is connected to the OTG port with a non-spliced cable. -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d_______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users Dipl.-Ing. Mark Stamer Technische Universität Hamburg-Harburg Institut für Mikrosystemtechnik (E-7) Eißendorfer Str. 42 21073 Hamburg Germany Tel.: +49 (0)40 42878 2402 Fax: +49 (0)40 42878 2396 Email: mar...@tu... http://www.tu-harburg.de/mst ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users -- Alexander Thomas Research Engineer eSATURNUS T. +32 16 40 12 82 www.esaturnus.com ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |