I am having a problem with my Fez Raptor. After several weeks of successful operation with various modules, the USB connection is no longer recognized and shows up in Device Manager as: “Unknown USB Device (Device Descriptor Request Failed)”, when I power it up, either normally, or with pin 8 & 10 connected on socket S. No comport shows up.
Previously I had successfully updated TinyBooter, but no longer can. Tried different USB ports on the PC, different cables, and with and without external PS.
PS at 7.5v draws 62mA, dropping to 35mA with reset pin pushed, so uP seems to be running. Using USB Client DP 1.3. All other modules disconnected.
FEZConfig cannot connect.
Tried again, and GHI NETMF Debug Interface (v. 6.1.7601.17514) appears in device manager.
Launch FEZ Config, and device G400_G400 appears.
Go to Firmware Updater, and get “windows busy icon” and then "The device is not ready for update!"
Go back to Connection, and device has disappeared, but still shows in Device manager.
Restart FEZ Config, device appears. Press “Check device for update” and get "Failure - Device is not connected or not responding"
Stop FEZ Config, press reset. Now Device manager reports "…Configuration descriptor request failed"
Try several times to reboot to update tinybooter (pin 8+10 connected), no luck.
My guess is hardware failure related to USB.
Any suggestions would be appreciated.
Thanks, and have a great holiday.
What S socket did you plug it into? Only 3 and 11 are capable of being used to update the Tinybooter. Please try again with one of those sockets.
Hi Aron:
I have been using socket 11.
I just tried again, and if I tie the two pins together reset, and release connection, I get no visible device in device manager. No comport has been generated. If I just press reset, then I get the Unknown USB Device (Device Descriptor request failed).
Did you connect any new USB devices to your PC, recently? Remove any other devices, try different USB port.
So can you tell us about what your application has been doing, in particular whether you’ve played with USB host functions?
Bootloader functionality is pretty fundamental, and reliable too. Any chance you can swap around your cables from the USB module to the mainboard and check for no bent pins etc?
Brett and Architect, thanks for the replies. I have not been playing with the USB host functions, but I have been using a Breakout module to access SPI on socket #3 for two high resolution ADC converters. I also have a joystick and T43 display attached. Using the Program.Gadgeteer panel in VS2012 I have not declared a breakout module to be present. I instantiate the AD converters in code. I hope this is the proper way to do this.
I took your and Architect’s advice and tried a different cable and different USB port with no luck. Then I unplugged my external supply, and the board worked. I was able to attach FEZ Config and refresh the firmware. I rechecked the power supply voltage and noise level and it seems OK. I reattached the PS and it still works fine.
I have marked the cable that may have caused the problem (no visible defect or bent pins), and set it aside. I have not found exactly what the problem was, but have several possibilities for further investigation.
Now I will get back to writing code…
Thanks for all your help!
Hi:
This problem has reappeared, and I am stuck and not able to understand how to further troubleshoot this issue. Any thoughts on what to do next would be appreciated. Here are my notes on what I observe (sorry it is long, but I have tried to include anything that might provide a clue as to what is happening):
The FEZ Raptor has been running for a month or so. When I came back to it today, it was still executing my software, but I could no longer connect in Visual Studio. When I pressed reset, the device would disappear then reappear on device manager and would start executing my software (bluetooth communications with T43 display).
I verified that it was connecting using USB (device manager finds “GHI NETMF Debug Interface”, but VS will not see it. Load FEZ Configure, press reset, verify Device Manager, but FEZ Config will not see the Raptor. Switch to Serial Port then back to USB and nothing is found, although the busy icon appears for several seconds and the program saw “not responding”.
If I reset the Raptor, switch FEZ Config to serial port then back to USB I will usually see “G400_G400” a while (2 seconds to several minutes) but then it disappears.
One time I was able to check device for update, and the attached screenshot is what happened, but the connection disappeared before I had a chance to do anything further.
I also followed the instructions to update the loader using SAMBA, and this completed correctly according to the Notepad log. Afterwards the behavior was unchanged.
During all these tests, the FEZ Raptor was connected to a USB Client DP 1.3, which was connected to a lab power supply.
This is independent of USB port and USB cable, and cable between Client DP and Raptor.
Detaching the display and bluetooth modules does not make a difference.
The application being developed deals with bluetooth, but does not using any USB functions beyond those required by VS.
The modules attached are a T43 display, Bluetooth 1.1, USB Client 1.3.
The GHI NETMF Debug Interface is Driver version 6.1.7601.17514 (9/10/12)
I was able to repeat getting into this position with another FEZ Raptor (my spare). Both Raptors were able to be updated using SAMBA after reseting via pins 8 and 10 using socket 11.
This is the end of the ourput from SAMBA produce logfile.log. I am including this in case it might contain a clue as to what is happening:
-I- Complete 99%
-I- Erasing: 0x3180 bytes at address 0x41EF80
-I using G400_Tinybooter.bin
-I- Send File G400_Tinybooter.bin at address 0x8400
GENERIC::SendFile G400_Tinybooter.bin at address 0x8400
-I- File size : 0x10838 byte(s)
-I- Complete 0%
-I- Writing: 0x3180 bytes at 0x8400 (buffer addr : 0x20008FEC)
-I- 0x3180 bytes written by applet
…
-I- Complete 93%
-I- Writing: 0x10B8 bytes at 0x17B80 (buffer addr : 0x20008FEC)
-I- 0x10B8 bytes written by applet
-I Using G400_Beta_Bootstrap.bin
GENERIC::SendFile G400_Beta_Bootstrap.bin at address 0x0
-I- File size : 0x2290 byte(s)
-I- Complete 0%
-I- Writing: 0x2290 bytes at 0x0 (buffer addr : 0x20008FEC)
-I- 0x2290 bytes written by applet
-I------------------------------
-I- Script Completed
-I- Please Reset the Device
-I------------------------------
When then loading FEZ Config, the device shows up as G400_G400, then disappears…
About the FEZ Config version:
FEZ Config 1.0.0.0
SDK Version: 2013 R3
- GHI Premium NETMF installed:
- EMX v4.2.11.1, Loader (TinyBooter) v4.2.11.1
- G120 v4.2.11.1, Loader (TinyBooter) v4.2.11.1
- G400 v4.2.11.1, Loader (TinyBooter) v4.2.11.1
- GHI Premium NETMF Library v4.2.11.1
- GHI OSHW NETMF installed:
- FEZ Hydra v4.2.6.1, Loader (TinyBooter) v4.2.6.1
- FEZ Cerb Family v4.2.6.1, Loader (TinyBooter) v4.2.6.1
- GHI OSHW NETMF Library v4.2.6.1
In checking the versions online I see there is a new version as of 2/1/14. Download and install.
FEZ Config is now 1.0.1.0. Try it, but it does not work any differently. Try updating TinyBooter again
-I- Complete 99%
-I- Erasing: 0x3180 bytes at address 0x41EF80
-I using G400_Tinybooter.bin
-I- Send File G400_Tinybooter.bin at address 0x8400
GENERIC::SendFile G400_Tinybooter.bin at address 0x8400
-I- File size : 0x108E0 byte(s)
-I- Complete 0%
-I- Writing: 0x3180 bytes at 0x8400 (buffer addr : 0x20008FEC)
-I- 0x3180 bytes written by applet
…
-I- Complete 93%
-I- Writing: 0x1160 bytes at 0x17B80 (buffer addr : 0x20008FEC)
-I- 0x1160 bytes written by applet
-I Using G400_Beta_Bootstrap.bin
GENERIC::SendFile G400_Beta_Bootstrap.bin at address 0x0
-I- File size : 0x2280 byte(s)
-I- Complete 0%
-I- Writing: 0x2280 bytes at 0x0 (buffer addr : 0x20008FEC)
-I- 0x2280 bytes written by applet
-I------------------------------
-I- Script Completed
-I- Please Reset the Device
-I------------------------------
** No change in inability to connect and maintain a connection using FEZ Config
** G400_Beta_Bootstrap.bin has a file date of 1/28/14 **
Any suggestions on what to try next are appreciated.
@ rockybooth - After reseting the TinyBooter via SAMBA, did you try to install the firmware with MFDeploy?
@ Aron - no - I must have missed something or don’t understand the process. I followed the instructions “Loader (TinyBooter) Update G400” which ends with “Reset the device and update the firmware (TinyCLR) with FEZ Config”.
I thought that MFdeploy was superseded by FEZ Config.
I can try MFdeploy if you can outline what I should do.
Thanks
@ rockybooth - Access MFDeploy and on the screen there is a choice to select serial or usb etc. Select USB. Another section says image file, click browse and navagate to the GHI folder where the G400 Firmware can be found. select both the Config and Firmware then click deploy.
MFDeploy is the generic Microsoft supplied Micro Frameword DEPLOYer. It can deploy to a netmf tinybooter device both the framework firmware and an application. Fez Config is a tool from GHI that can deploy their firmware to their devices, so it doesn’t really supersede mfdeploy.
One thing that can catch people out is that the debug engine needs the processor on the board to be able to respond to debug requests. So if your application has little/no spare time (thread.sleep()'s) then you often fall into this situation where you need to erase your application before you can debug again. So here’s two quick suggestions: add a thread.sleep(5000) at the start of your application, so you have a chance of getting into debug in that phase, and if you have a tight loop as the main process of your app with no thread.sleep, add one, and see if that helps.
@ Aron: I cannot get MFDeploy to connect to the Raptor. When I press reset on the Raptor after connecting MFDeploy, nothing is shown on USB, but Device Manager shows “GHI NETMF Debug interface” as present on USB. Periodically, MFDeploy will show “Not Responding” for a few seconds, but no connection will be made.
I assume this is not normal. What else can I try?
@ Brett - I think that might have been the issue that started me down this spiral as I have been speeding up timer interrupts to see how fast the system could process when the problem happened. I was under the assumption that the erase cycle that SAMBA goes through would erase the program code, and get me back to the start. Unfortunately I cannot communicate with either board at this point.
.
@ rockybooth - The samba erase will erase the entire system. you may need to clear the bootflag especially if it is still in tinybooter mode once the firmware is loaded.
@ Aron - how do I clear the bootflag?
@ rockybooth - From MFDeploy: Plug-in -> Debug -> clear bootloader flag
fez config: advanced -> reboot clr
@ Aron
From MFDeploy: Reports “Clear Bootloader Flag Complete” but still cannot with USB. Before trying the Clear, the device could not connect - so if this flag is in the device, could if be cleared?
@ rockybooth - What are the details of your PC? USB port type (2.0, 3.0 etc), OS, etc.
@ Aron - both usb2 and usb3 ports tried. No difference. Both through a hub and direct - no difference.
Running Win8.1/64. 16GB ram.
Raptor shows USB driver: GHI Electronics, 9/10/2012, vers 6.1.7601.17514
@ rockybooth - Perhaps try to completely uninstall the GHI SDK again and re install it. Maybe something corrupted the firmware? Also, if you have another PC, see if that one will work as well.
@ Aron - I installed the latest software on my laptop and it worked - I could execute FEZconfig without problems. So, the lab computer is the issue…
I uninstalled all the GHI software, and downloaded the latest version from a few days ago. I had already installed, but uninstalled and re-installed anyway.
Unfortunately, no change. I also un-installed and reinstalled the drivers for USB with no luck.
I started to unplug other USB stuff, and the problem seems to have disappeared.
So, this is due to some kind of USB conflict, that does not seem to have anything with GHI…
Thanks for your help