On Thu, Nov 17, 2011 at 10:35 PM, Andrew Gottemoller <[hidden email]> wrote:
> I'm attempting to connect a Robovero to a Windows PC. First I give the
> Robovero power, and the red LED turns on (does not flash, stays red). I
> then connect the USB, and the green LED turns on. Windows say "USB
> Composite Device Found". Shortly after, Windows hangs.
I cannot see the main post but I do see your reply. I have 3 Roboveros and have the same or a similar issue.
On Windows XP when you connect it says new hardware is found and goes through the installation process and in my case completes. However, windows becomes screwy and freezes causes other things to stop working and I must restart the computer with it no longer attached to solve the problem.
A similar thing happens on a Windows 7 computer although it is less severe.
I have tried BOTH allowing the RV to install the drivers automatically as well as try the ini file method found on the robovero.com website. No matter what the boards will not connect to a Windows machine.
They work fine on the same computers running Ubuntu 10.04 LTS.
To be more specific, it is not a driver problem.
When the RoboVero is powered off and then connected to Windows XP three devices are detected by Windows.
First, a USB Composite Device named "Dual RS232"
Next, two USB to serial converters (A and B)
So far this makes sense according to the hardware.
Next, you power up the RoboVero and Windows recognizes another USB Composite Device "Robovero".
The "USB Composite Device" will appear fine (no red or yellow exclamation points indicating an issue) however, if you click properties it says there is no driver installed despite ALSO saying that the generic Microsoft composite driver is loaded.
Essentially, the device manager is now frozen. If you scan for new changes, or run a tool such as USBDeview they freeze. You will be unable to shutdown Windows properly (without holding the power button) and unless you unplug the robovero or at minimum power it off, the PC will not boot after either.
It is as if the process becomes stuck at the end of loading the USB Composite device driver or the beginning of loading / discovering the RoboVero's LPC17xx USB connection.
It does not matter if the driver is installer before or after this process, it always breaks windows.
To be even MORE specific I have now solved the problem with the firmware and am communicating in through Windows (but used Linux to flash firmware).
First, let me say that I wish the Robovero firmware was organized as well as the Overo OS builds. Folders named with dates and easily accessible to previous versions. I am not sure which version of the firmware I have but I know it has been silently updated once since I started working with the RoboVero.
The problem lies with the file in firmware/src/usb/usbdesc.c
My files says this:
* U S B - K e r n e l
* Name: usbdesc.c
* Purpose: USB Descriptors
* Version: V1.20
Around lines 75 / 76 there are two lines which seem to have been accidentally copied twice.
Delete both lines or comment them out. IMPORTANT: make sure to also now remove the "+" symbol from the new last line (my line 74) as there is no no longer any more - it ends at this line.
0x03, /* bNumInterfaces */
In my version of this file one of the three interfaces is completely commented out. Therefore this should be changed from 0x03 to 0x02
Line 157 (under the section "Call Management Function Descriptor"
USB_CDC_DIF_NUM, /* bDataInterface: CDC data IF ID */
I changed this line to "USB_CDC_CIF_NUM," (Notice the C instead of the D)
I then rebuild the firmware, flashed, and tested in Windows. It worked. I had already been messing with the INF file driver from the robovero site and tested with a customized version. I think the file provided is likely to work, if I later find out it does not then I will share my changes.
As a note, my proposed changes above are after reflection and comparison of the firmware to the libraries provided by NPX for the LPC17xx chips and reading the USB standard. I am not sure if the last change is necessary but it seems to match up better with the examples from NXP.
I've tested your changes on both Windows 7 and XP with the default INF file and they work. You need to change internals.py to tell it to connect to a COM port rather than a ttyACM port to run Python code. That last line with USB_CDC_CIF_NUM, does break compatibility with Macs though.
These changes solved my Windows hanging problem as well.
I do not think the last change (USB_CDC_CIF_NUM) is correct though. Changing this line caused my Linux PC to no longer connect to the Overo attached to the Robovero. Keeping this line as-is kept Windows and Linux working correctly.
I've tested your changes on both Windows 7 and XP with the default INF file
and they work. You need to change internals.py to tell it to connect to a
COM port rather than a ttyACM port to run Python code. That last line with
USB_CDC_CIF_NUM, does break compatibility with Macs though.
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
Only if you could get it to connect correctly in Windows - but then
you wouldn't need this fix. Once the fix is done the first time you
can program through Windows later. You can either install Linux
which very easily will setup a dual boot for you, or you could try
to run it from a live CD instead of installing it. Not sure how well
that would work but it might be possible.
Recommended Ubuntu 10 LTS and NOT Ubuntu 11. Goodluck.
On 5/21/2012 6:37 PM, asynchronous13 [via Gumstix] wrote:
> These changes solved my Windows hanging problem
I'm having this same problem, but I do not have easy access to a
machine. Do I have any options to fix this using only Windows?
On Wed, May 23, 2012 at 9:10 PM, Danny Chan <[hidden email]> wrote:
> The changes should have been pushed to Github (both the firmware and Python
> Library), but yes, you are correct. Only the other two lines are necessary.
Confirmed. I pulled from the git repository yesterday and rebuilt the
firmware. It works, and no code changes were required.