Chipworkx Dev Kit Just Arrived Yay! USB not working :(

[analoguebus]

Like some others on here I am using Windows 7 64 bit. In the past I have had no troubles with your devices FEZ, Chipworkx, and Embedded Master (well on other os except FEZ whoch works perfectly on Windows 7). I followed instructions like all the others putting the machine into test mode with F8 etc. It installs the driver if I do it manually with install legacy drivers or use hdwwiz.exe (really the same). I do not get the 52 error about signing. I get error 10 that it is unable to use device. I have another issue popping up when I plug the Chipworkx in it pops up that it is an unknown USB device. So down in device manager in the USB section I get a bad USB symbol thats of driver type Unknown USB Device. From the experiances I am hearing from others it does not sound like they get that error. I also did not get that error with the FEZ. I have basically tried all drivers that you have. The device powers fine starts playing the music and lets me do the demos. A long while back using a different e-mail when the embedded master first came out I was talking to Mike I think on the phone and he emailed me a new driver. I dunno if you have one ready or perhaps my USB port is bonkerd on the device, since like I said I can flip over to NETMF 4.0 and the FEZ and it works flawless. I have not tried the EM on this setup. When installing Chipworkx btw I got rid of everything.

Any ideas?

Sorry for long post.
Bryan Small

[SupportAdmin]

Fez and chipwork use the same drivers. The drivers are signed and been tested on win7
maybe your USB port is providing enough power for chipworkx. Try to power it up using a power supply or use a powered hub

[support]

SupportAdmin forgot to mention that this will be true with the new ChipworkX NETMF 4.0 firmware, coming next week.
For now with you ChipworkX, with NETMF 3.0, you will need to disable signature check (F8) on windows start up and you have to use the driver included with ChipworkX SDK.

[analoguebus]

Like in the first post I said or maybe said it wrong I tried both the new SDK driver like you said at beginning of post which I would think like your last post says should not work on the 1.0.1.00 firmware maybe I am wrong. But I have also like I said in first post have attempted to use the original driver first the one that comes with the current Chipworkx. I also tried it both off the powered usb port on the laptop and off of a hub plugged into wall. I also used a wall wart. I cannot seem to find the one I originally used with the embedded master when it came out. I don't think you will remember but I had you send me your recommended wall wart. That was a long time ago though. The wall wart I used did not have quite 1 amp of current had ~750ma and sat at 9 volts. If needed I can hook it to my benchtop power. I originally was thinking that it could be a usb undervolt issue but I got that covered with both psu and powered hub. I also did the temp. signed driver disable with [F8] and did the newer perm Test Mode setter. I know its in Test Mode and will use unsigned drivers since the watermark pops up in lower right corner. The error code coming back when I forced it to load the driver was cannot start device error #10 not the error #52 that is typical of unsigned drivers. The big big thing that worries me is that from the get go the first time I plugged it in it did not recognize it as a GHI device it says its an unknown usb device error #42 (I think is the error #). On the FEZ it popped straight up. The FEZ did not even mind running on a Mac with VMWareFusion passing the USB off to Windows 7 Ultimate x64 it worked flawlessly. The main thing I wanted to be assured of was that the USB client hardware was not messed up. I mean it works to point of supplying power and getting recognized perfectly by the mac or fusion (just like FEZ and in past embedded master on my XP host) Fusion shows it at a GHI Chipworkx something or other then Windows 7 tries to pick it up while its playing that lovely song :p Thats when it dies. If I remove it all even the driver out of the spot in Windows and put back on the latest SDK from tinyclr and microframework 4.0 and hook up fez all is well.

Hopefully this rambling mess makes sense had to type it out fast. If I need to call like I did in past or email one of yall I can.

Thank you for the wonderful products so far. They specially the newer FEZ and (hopefully) the Chipworkx is going to massively accelerate our initial prototype date.

Also thank you for any diagnostic info you have been able to do so far and hopefully soon to resolve this issue.

Cheers,
Bryan Small

[SupportAdmin]

You will not be able to use the new driver until you upgrade the firmware to 4.0. Once you have 4.0 (next week) all driver signing issues will be gone since the new driver is signed plus you have already used it the driver with FEZ.

For now, you need to use the driver that ships with 3.0 ChipworkX SDK.  This driver is not digitally signed and so you will need to disable signature checking on your PC powers up. We have used ChipworkX on 64-bit machines and windows7 so I am not sure why you are having an issue. If you have another PC that is not 64-bit then try that for now.
All you need really is a week  of patience till 4.0 is available then all will be fine.

[analoguebus]

The big question that has not been answered yet for me is this. The FEZ fresh out of box when plugged in gets recognized as something besides a non-functional unknown usb with error 42. Is it standard right now (I am indeed doing the signing trick my machine is in Test Mode etc. etc.) but is it standard when you plug in the Chipworkx that it throws out some wacky USB detection message? Or should it say 'GHI blah blah...'? Thats the main gist of all these questions the Embedded master and the Fez did not act this way when the USB host of Windows picks up the new device and tries to match it by its attributes. I have wrote a bit of USB driver logic in the past so mainly was just wondering why it has 0 clue about the device. Does all Chipworkx on thier current firmware act this way? I am just wondering about this one. Oh I am def. waiting patiently for next weeks release of Chipworkx beta I still have my other GHI toys to play with. It was just alarming a bit to take it fresh out of box mess with it all night trying every weird thing in the world and never get it to work. I mean it would never like I said every time I plugged it in Windows acted like I just plugged in one of my old horrid usb creations (<- means blows up on detect :p ). Just a bit nervous having $400 sit there and only thing so far I can do is watch the demo.

Not a problem though. Is there perhaps a way to get a pre-beta firmware and driver (even if its really buggy, right now I am still writing all of the framework for the application and can use the FEZ) to just assure me its ok on the detect and on (i.e. MFDeploy can ping it and see the device attributes) when I manually installed the debugger drivers and they came up with error: 10 device not functioning. And of course since Windows set them at error: 10 it cut em off so MFDeploy will not ping them. And same with the 256 meg flash it does not show up even when I install the correct driver in the unsigned test mode and same with the virtual COM port. If I can just see those two things go away I can patiently wait a long time.

Thanks so much sorry for all the hassle. We just got some scary promises out there and are looking forward to bulk ordering the DIMM MINIChipworkx. We got to get a bunch of them and a bunch of FEZs.

Thanks
Bryan Small

[SupportAdmin]

Chipworkx is slightly different because it's USB shows as a composite device.
You do not need a pre beta as beta is only couple days away!

[analoguebus]

I found out the issue (I wish I had had the USB port sniffer hardware from long ago ) sorry to have been a big hassle. Here is what seems to be the issue. The only reason I can think the FEZ work is the embedded USB is different...I dunno but when running in a virtualized environment well at least VMWARE Fusion (should be all that do this) on a few composite USB devices they do not like getting the get configuration command once again. Since the host OS is going to ask for it and it does do it and OS X finds it perfectly (shows up as a GHI Chipworkx), but as soon as it passes it to Fusion, Fusion fires a second get configuration, at this point is when it fails. For some reason after the first the USB hardware goes into a "state" that does not like getting a second which seems really odd never seen this but was talking to some USB guys and found an article on it. It is really just a fluke. Some other composites are known to produce the same error. some of the newer Blackberries, etc. Long story short it works fine on my main non virtualized dev machine. At the point I received it I was away from that machine so had no way of testing. My main dev machine is Win 2008 x64.

Thanks for putting up with my mindless drivel. Now to get finished with the core framework so we can start integrating these and hopefully getting some prototypes out the door.

Cheers
Bryan

[analoguebus]

Sorry but I got to correct myself I guess it is too early @_@ I was meaning Set Configuration I do not know why I was saying get configuration.

Thanks

[SupportAdmin]

Set configuration multiple times!? Is this even supported in standard USB specification? Doesn't sound okay to me to set some config but then out of nowhere someone may want to set it again?! There has to be a bus reset before that can be done. I could be wrong but it doesn't matter since NETMF doesn't support that I guess

[analoguebus]

Its two different operating systems remember? I said it was running OS X running Fusion that is hosting Windows 7. This is all fine and great on FEZ. But the fact is BOTH of the OS are going to enumerate the USB devices when it senses a plugin. At that point it starts all over, but remember OS X has already done the enumeration on device and set configuration/etc...then when it hands it to Fusion and Fusion hands it to OS the OS of course thinks its a fresh plugin so it enumerates and does everything again. This typically is not a problem but VMWare has found some composite devices will "mess up" the second time it gets hit (as in when it gets detected in the host).