FEZ Spider - Unable to recognize device

Archive
#1

I’ll start with the disclaimer that while I’ve been writing software professionally for well over a decade, I am a complete newbie when it comes to hardware.

I just got my Spider starter kit this week and am currently trying to update the firmware on the Fez mainboard. I can’t for the life of me figure out how to get the device to be recognized by my laptop. When I try to connect the USB cable, I get a “USB device not recognized” notification. The device manager shows an Unknown Device reporting error “Code 43”. I’ve tried this over and over with the DIP switches set to the default position (all off), to the loader position (off-on-on-on), and to the tinybooter position (off-on-off-on). Failure every time.

I also tried this with and without the LCD panel connected. It’s probably also worth noting that the LCD panel always displays a blank white screen when the board is connected to USB. I’ve never seen it display anything else (and from reading forum threads, it sounds like it should be displaying some basic firmware information).

I’ve manually installed the drivers included with the SDK:
C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\USB Drivers\GHI_NETMF_Interface
C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\USB Drivers\GHI_Bootloader_Interface

One last thing worth noting is that my laptop is running Windows 8.

#2

Dan - Welcome to the forum.

The blank white screen on the LCD usually indicates your USB port is not sourcing enough power. Also, is it USB3? I had some troubles getting my boards to work with USB3 ports on a new laptop (regardless of OS). Try using a powered USB2 hub between your laptop and the Spider.

#3

The ports I was testing were all USB2. I just tried it with a desktop PC where I was sure that the USB ports were all powered and I had a little bit more success, but it didn’t last. When I initially connected the Spider, it detected it the device correctly (I think?). In the Device Manager I saw a device called “EMX” with a question mark next to it. I clicked on the device, selected “Update Drivers”, and pointed at the drivers included in the SDK. At this point, the device name changed to something like “.NET MF debuggable device” or something like that (I can’t remember exactly and now I can’t reproduce it). Unfortunately, the DIP switches were set to the tinybooter configuration, so I unplugged the device, changed the DIP switches to the loader position (off-on-on-on), and then plugged it back in. Again, I got a generic looking device with a question mark, and upon selecting Update Drivers, was presented with something reasonable (the device name included the word “bootloader” and the device was located under the Ports category in the DeviceManager.

At this point, I thought all was well so I fired up the FEZSpiderMainboardUpdater.exe. Turns out I was a bit premature in my celebration. The firmware update immediately failed just as it had done every previous time with an error dialog stating: “Cannot connect to the device!” I unplugged the USB and plugged it back in again and now I’m in the same state I was in with the laptop. No matter what I do, I get a “USB device not recognized” notification. I tried another USB cable that I have for an external harddrive thinking that perhaps the cable itself was the problem, but that didn’t seem to make any difference.

Any more suggestions?

#4

I just checked the event log and see the following two events occur each time I plug in the device:

EVENT #1: "Device USB\VID_0000&PID_0002\5&1f35f9f3&0&6 was configured."
EVENT #2: “Device USB\VID_0000&PID_0002\5&1f35f9f3&0&6 had a problem starting.”

The VID being all zero seems a bit odd to me. When I look at the details of the Unknown Device in the Device Manager, the Hardware Ids property shows “USB\DEVICE_DESCRIPTOR_FAILURE” which I guess would explain the suspicious looking VID. It looks like the OS is failing to get a reasonable USB device descriptor off of the device following the initial handshake. Looking further back in the event log, I see the two lines events from when it successfully managed to install the driver:

EVENT #1: Driver Management concluded the process to install driver ghi_netmf_interface.inf_amd64_f622f3d09947a4a2\ghi_netmf_interface.inf for Device Instance ID USB\VID_1B9F&PID_0102\5&1F35F9F3&0&6 with the following status: 0x0.
EVENT #2: Driver Management concluded the process to install driver ghi_bootloader_interface.inf_amd64_42ac7ea18a575552\ghi_bootloader_interface.inf for Device Instance ID USB\VID_1B9F&PID_0104\5&1F35F9F3&0&6 with the following status: 0x0.

Any idea why the device manager is now failing to pull the correct device descriptor from the board? Could this be an indication that the USBClientDP board is bad? Or perhaps the Spider mainboard itself?

Any more troubleshooting tips?

#5

Same background experience, Win7x64 machine and I’m having the exact same issues (maybe it’s a sign). Looking forward to a solution to this problem. I’ve also resorted to additional DC power sources, same white screen.

#6

And here is how the last hour went (almost looked like it would work too).

Re-ran installer, selecting the legacy USB drivers this time (only option unselected by default).

Finished installing.

Connected device, shows in device manager correctly (Debuggable .Net Micro Framework Device, which a child item of GHI .NET Micro Framework USB Debugging Interface).

Ran up the Helloworld app (the button, camera, LCD one from the starter guide)

Failed deployed. Last time, could not connect issue (prior to reinstalling drivers with legacy USB). This time, assembly mismatch, ie, firmware out of date (as expected, so making progress).

Run C:\Program Files (x86)\GHI Electronics\GHI .NET Gadgeteer SDK\Firmware Update\FEZSpiderMainboardUpdater.exe

Reports current firmware is 4.1.8.0 (sounds about right since I bought the unit a while ago, and the sticker date on the blue lunch box it came in read 4/13/12, or 13th April 2012 where I come from). PS, version of updater (label in bottom left of startup form) is 1.0.7.

Click next.

Unplug USB. Plug back in. (for the hell of it).

My LCD screen is still plugged in (and showing a lovely shade of white).

Leave tiny booter/firmware paths alone,
C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\EMX\Firmware\TinyBooter\TinyBooter.GHI
C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\EMX\Firmware\Config.hex;C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\EMX\Firmware\Firmware.hex;C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\EMX\Firmware\Firmware2.hex;

Click Step 2.

Flick switches 1,2,3 to on (in that order).

Hold reset switch (about two seconds) and released.

Device Manager flicked about and the device showed up again (same as above).

Click Update. Fails, dialog about repeat again or click here to do it manually.

Pull USB, flick switches back to default (all off).

Over to GHI Electronics – Where Hardware Meets Software

Install TeraTerm, full install.

Run TeraTerm Pro. No serial ports. Quit application.

Close TeraTerm.

Connect USB.

Manually install BOOT loader Interface (Device Manager, Add Legacy hardware, select the GHI BootLoader item).

Shows up now with a warning (ie, could not start) as COM3.

A hole lot more mucking around (switches, reset, unplug, install/uninstall) to no end… The bit about “shorting pins” I translated to dip switches, which made sense when you read the different in pin shorts between loader and tinybooter requirements.

Give up, download 4.1 SDK, install.

Switch VS HelloWorld project over to MF 4.1, recompile, run.

All is sweet. I’m going to play with 4.1 until the 4.2 is stable/workable. I followed all the guff about changing USB2/3 ports, powered hubs but found it had nothing to do with it (even tried the good old cable swap). Try 4.1 to prove your hardware is ok (mine is) and re attempt 4.2 if you have the patience (I don’t).

:slight_smile:

#7

Thanks for sharing your frustration, I am having a ‘me too’ experience.

Newly downloaded development environment on a newish PC (VS 2010 express and all GHI components loaded in the right order).

Manual install of the drivers working.
First demo build under 4.2 (spider board only and “Hello World” debug print) would not load with some GHI Premium libraries missing / mismatch debug message on the output window.
I could get a simple MF program working OK (used the MF console application)

All attempts to update the firmware resulted in a “device not recognised” error.
The switch numbering and the cardboard “cheat sheet” orientation are different, which is slightly confusing (unless I got the Australian version :wink: )

It would be really nice to have a simple checklist for installing everything correctly. Eash ‘basic’ tutorial seems assume different pre requisites (firmware OK, SDK and drivers already loaded).
I would really appreciate a guide for (otherwise intelligent) newbies to GHI hardware that covers all of the steps.
Thanks
S

#8

Go on Brett - an eloquent reply from the Antipodes is required :smiley:

#9

zippin it… :wink:

Guys, the one thing I see in this sequence that is strange is the switch settings:

[quote]Flick switches 1,2,3 to on (in that order).

Hold reset switch (about two seconds) and released.

Device Manager flicked about and the device showed up again (same as above).
[/quote]
At that point the device should NOT show up as a debuggable .netmf device, it should show up in bootloader mode as a COM port. That to me says perhaps the switch didn’t close (and I’ll ignore the comment from the old blighty :wink: Hey I’m allowed to say that, I know my family lines run back to convict days! )

@ Steve, I agree with your comment. There’s a sequence of firmware update posts GHI Electronics – Where Hardware Meets Software that are out of date, so it might be worth putting some effort into getting that clearer and updated for current firmware versions and SDK versions.

#10

4.2 is about done. We just tested SSL and working on the last couple little issues. Once it is out, all we will do is update documentation and tutorials.

#11

4.2 is about done. …

Great! I sure hope you folks provide a nice WiFi sample!

#12

We have it. You need to complain to Steve about not seeing it in codeshare yet :wink:

#13

At that point the device should NOT show up as a debuggable .netmf device, it should show up in bootloader mode as a COM port. That to me says perhaps the switch didn’t close (and I’ll ignore the comment from the old blighty :wink: Hey I’m allowed to say that, I know my family lines run back to convict days! )

@ Steve, I agree with your comment. There’s a sequence of firmware update posts GHI Electronics – Where Hardware Meets Software that are out of date, so it might be worth putting some effort into getting that clearer and updated for current firmware versions and SDK versions.
[/quote]

You might be on the right path here. I flicked over to “loader mode” and watched the screen more closely. Reads booting in “Tinybooter mode”, which to me suggests dip switch two is not making contact (the only difference between the modes). Will explore getting it working, or worst case, shorting the pins from the top of the PCB manually around 1,2,3 switches.

Thanks for the reply

#14

So to bring this thread back to its origin, I am still completely stuck trying to get Windows to recognize my device. Every time I plug it in to either my laptop or my desktop, using a variety of different USB ports and USB cables, with every combination of DIP switch settings, I get a “USB Device not recognized” error, and in the Device Manager I see that Windows failed to retrieve a proper USB Device Descriptor from the board.

At this point I’ve got a nice $300+ paperweight sitting on my desk. :frowning:

Is there anything else that you guys can suggest I try?

#15

How are you powering your board?

#16

Via the USB cable that came in the kit. I’ve also tried using another USB cable that came with an external USB harddrive that I had lying around. I should also mention that at this point I don’t have the LCD Panel connected as I thought that perhaps it was trying to draw too much power - it’s just the Spider mainboard plus the USBClientDP board.

#17

We always recommend using powered hub or power pack. Relying on the PC power is not a very good idea.

#18

Only insight I can offer is that I missed ticking the “USB Legacy Drivers” when installing the GHI SDK. Prior to that, my issue mirrored yours and Windows didn’t recognize the device. Once installed, found/worked straight away.

#19

OK. I’ll pick up a power supply tomorrow and try it out. In the event that that doesn’t work, what would be my next step?

Also, if that truly is the problem, might I suggest that you add some language to the effect in your setup instructions / tutorials? I read through everything I could find over the last week or two and don’t recall seeing anything that said I would have problems relying purely on PC power, especially if I am not trying to do anything fancy with lots of modules that each demand power.

#20

User_10512, my problem is not so much that Windows is unable to find usable drivers, but rather that Windows is completely unable to get a USB device descriptor off of the board that it would then use to select an appropriate driver. I’ve seen it successfully get a device descriptor and then load the correct driver a total of 3 times now over the 100+ times I’ve attempted it, but in none of those cases was I able to then proceed with the firmware update. If Gus is right that the PC is simply not supplying sufficient power, then those three partial success could have been caused by having JUST enough power to manage to get a device descriptor transferred over, but then not enough to actually work beyond that point.

That said, how much power does this thing need? I mean, I’ve got an external HDD that is powered purely off these same USB ports that I’ve been testing against. I would have assumed that power required to spin the platters in the HDD would be more than what’s required by my little Spider board with no models attached…