Main Site Documentation

Tale of woe attempting to update FEZ Spider loader


#1

I’ve spent several hours going in circles on this, trying in vain to get the system to see the FEZ Spider in loader update mode.

Using a Windows 7 32-bit PC with the latest GHI SDK freshly reinstalled yesterday, with the Spider switches in normal mode, FEZConfig sees the board and confirms that it needs both the loader and firmware updated.

But as soon as I connect the Spider in loader mode (last three switches ON), the device is not recognized. In FEZConfig, the status bar shows “No device.” In Device Manager, it shows up under the USB section as Unknown Device. I tried having it update the driver by searching in the GHI folder on my system, but it just says that it has the latest driver for “unknown device.”

If I attempt to load the GIH bootloader driver manually via the INF file, I get a message indicating that the driver cannot be installed this way. If I try updating the driver through device manager, and specify the GHI bootloader driver specifically, half the time it just says that the “unknown device” driver is already up-to-date.

Now, the other half of the times I do this, it SEEMS more promising, saying that a Windows restart is required. So, I restart Windows, and Device Manager shows the GHI Bootloader driver as COM3, but in a state of being “unable to start.” Disabling and re-enabling the driver ends up in the same “unable to start” state. Bringing up FEZConfig shows “No device” and if I switch to Serial mode from USB, COM3 doesn’t show up in the list.

On the rare occasion that I see the “unable to start” GHI Bootloader driver in Device Manager, as soon as I press reset on the Spider, the GHI Bootloader device disappears, and the USB Unknown Device reappears.

A seemingly vicious circle. Any ideas how I can make more progress toward updating the loader on the FEZ Spider?

Thanks.


#2

Try a computer with only usb2 (old)
Try a USB hub
Try a powered USB hub (rare But cheap on eBay)


#3

@ njbuch -

Thanks for your reply.

Yes, the computer is old, with USB 2.0 only (no USB 3.0 at all, and no way to even add USB 3.0).

I have tried connecting the Spider to built-in USB 2.0 ports on the motherboard, USB 2.0 ports on an add-in PCI card, and USB 2.0 ports on an external powered USB 2.0 hub. No changes in behavior.

All USB ports I’ve used on this machine and hub were confirmed to work with other devices.

So, unfortunately, the USB ports don’t seem to be the issue.

Added notes: This is a desktop system, not a laptop. I have also tried three different USB cables, all supplied by GHI with USB Client power modules. Out of desperation, I uninstalled and reinstalled the GHI SDK again today, hoping it would clear up any configuration issues. No change in behavior.


#4

Some additional info.

I tried going through the manual steps outlined at https://www.ghielectronics.com/docs/54/loader-tinybooter-g120-and-emx-families, but noted that (a) after switching to loader mode, I got the same Unknown Device, and (b) in step 8, no new COM port showed up in TeraTerm.

I have noticed that, if I uninstall the Unknown Device in Device Manager, and then rescan for hardware changes, it still reappears as an unknown device, but sometimes (about 60% of the time) asks me to restart Windows. After the restart, I see that the Unknown Device is gone and the GHI Bootloader (COM3) device is listed in Device Manager, but is in the “unable to start” state (code 10). Attempts to disable and re-enable this device just toggle between “unable to start” and “disabled.” And as soon as I hit reset on the Spider, the GHI Bootloader disappears and the Unknown Device reappears, completing the circle of life.

Continuing to grab at straws…

Still open to any suggestions.


#5
  1. remove all modules connected to your fez spider, use only your DP module.
  2. use as short cables as possible. short USB cable, short cable between spider and power module.

I have one raptor that wont flash if i dont confirm to the above mentions


#6

@ RobvanSchelven -

Thanks for your reply.

This is a brand new Spider, and I have only ever had just the USB Client module attached to it. I have never attached any other modules to it, before or during this process.

The Gadgeteer cable between the USB Client module and the Spider is the one that came with the USB Client module. I don’t have any cables shorter than this one. I do have some longer ones available, but the one attached is the shortest one I have.

The USB cables I’ve used (three different cables, all supplied by GHI with USB Client modules) to connect to the PC are the shortest cables I have.

Keep in mind that, when the board is in normal mode (all switches off), the board is seen as an EMX device, can be pinged by FEZConfig without a problem, and the versions of the loader and firmware can be detected by FEZConfig without a problem. It’s only when the board is put into loader mode (last three switches on) that FEZConfig can’t see it at all (even under the Advanced loader update section), and we get into the mess of “unknown device” and non-functioning “GHI Bootloader” devices.

Are you suggesting that I try to purchase or build shorter USB and Gadgeteer cables, even though the existing cables work great with this Spider in all modes except loader mode?


#7

More info:

I have tried using a USB Client DP module and two different USB Client SP modules (each in socket 1, per the instructions), and have had identical results with each USB Client module.


#8

@ kgcode - No, i am not suggesting a shorter cable. I guess its an issue for @ GHI


#9

@ GHI -

I’ve spent two solid days trying to get this Spider loader updated, and have made no progress, as outlined and detailed above. Any assistance would be much appreciated.

Thanks.


#10

@ kgcode - Can you try to update with another computer? We have seen a few of these Code 10 issues come up recently and we are trying to resolve them. Switching to a different computer to update has sometimes helped.


#11

@ John -

Thanks for your reply.

I have several other computers available, desktops and laptops, running either Windows 7, Windows 8.1, Windows Vista, or Windows Server 2008 R2. Some are 32-bit, some are 64-bit. Rather than choosing one of these at random, can you suggest any attributes of the “other” computers that seem to succeed at the update? If not, I’ll just choose one.

Thanks.


#12

@ kgcode - We haven’t really seen a pattern yet so any of them will do except for Vista which is no longer supported.


#13

@ John -

Thanks so much for your suggestion to use another machine. In short, it worked!

It took some time, because I had to install Visual Studio 2012 on this machine, as a prerequisite to installing the SDK. But as soon as I reset the device with the Spider’s switches in loader mode, the device was immediately recognized as GHI Bootloader COM3, and the update proceeded without a hitch.

If you are keeping score on the types of configurations that work and don’t work, here is my info:

The machine that WORKED: I7-3770K 3.5GHz (overclocked to 4GHz), Windows 7 Ultimate 64-bit, ASUS P8Z77 motherboard (with USB 2 and USB 3), 16GB RAM.

The machine that DID NOT WORK: Pentium 4 3.0GHz, Windows 7 Professional 32-bit, Intel D875PBZ motherboard (with USB 2 only), 3GB RAM.

Suggestion: I think this is the sort of tip (using another machine if the Code 10 occurs) that should probably be in a release note, or in some prominent place…even a printed notice shipped with the board. It would have saved me a lot of time and grief, had I known this was a possibility when the board arrived.


#14

@ kgcode - Glad to hear you got it working. It will definitely be in the release notes if no fix for it is found soon.


#15

I can easily reproduce the issue on multiple different PCs. I captured the logs with Usb Beagle Analyzer:

  • UnknownDevice: Enumeration process fails during get configuration descriptor command. Fez spider sends stall in status stage.

  • UnknownDevice(Fez not connected to external power supply): Enumeration does not even start:

  • Code 10 on Ghi Bootloader: device enumerates successfully. Error during transfer on non control endpoint.

I also attached image from PC when the bootloader works correctly


#16

In addition, on PCs where bootloader fails to enumerate, “GHI NETFM Interface” enumerates without any problems.


#17

@ pgierasi - Thanks for the information, we will take a look.


#18

@ John -

Well, in the previous (R2) SDK release, just trying one other machine to do the loader update worked for me (posted here 1 month ago). Today, I installed the R3 SDK release, and tried to update the Spider loader, without success:

  1. Tried it on my main NETMF machine (where it had failed before), hoping for the best. It failed the same way - no device seen once the switch was moved to loader mode.

  2. Tried it on the machine were the R2 update had worked before, but alas, it wouldn’t see any device after moving the switch to loader mode.

  3. Tried it eight (8) other PCs with various configurations, all using USB2 ports. All got the same result…no device seen at all once the switch is in loader mode.

So, 10 machines tried, and 10 machines failed. I tried each one multiple times, making sure I was following the steps to the letter.

Once the switch was in loader mode, FEZ Config reported “No device,” and no amount of resetting would change that. Device Manager did not show any device attached when the board was set to loader mode. I verified this on all 10 systems. Not even an unknown device code 10 entry…nothing.

I confirmed the board is still working by loading my latest application on it, and it runs just fine.

So, after a day of installing the R3 SDK on 10 machines (and VS2012 on 7 of them that didn’t already have it), I am still not able to update the Spider loader.

Any suggestions? I have officially run out of computers to try.

Edit: To be clear, I am trying to update the loader to 4.3.4.0 through FEZ Config | Advanced | Loader (TinyBooter) Update | FEZ Spider.


#19

What is your current firmware and loader versions? There could be something in that so it’d be important to know.


#20

@ kgcode - Not even a COM port shows up when you put the switch to loader mode?