Main Site Documentation

USB Device Not Recognized - Cerberus, Cerb40


#1

After several weeks of no issues, after downloading a program from VS to the Cerb40, Windows8 came back with Device Not Recognized.

I plugged in my spare Cerberus main board, and it was recognized. So I downloaded to it, and now it is not recognized either.

What to do? Two dead modules.

This is using USB, direct to PC, no hubs, tried multiple ports. Tried reinstalling GHI USB drivers using the setup program. No external power or connections. Just the modules.

Nothing special about the program. Run an RLPLite command, print a debug string, and then while(true);


#2

Try to reload the firmware. Just a thought.


#3

Great. How? Link?

I uninstalled all the GHI software and reinstalled it. When I plugged in a Cerberus, Windows Device Manager showed a yellow triangle next to GHI Debug Interface.

I unplugged that board, and plugged in the Cerb40. It then said USB Device Not recognized, and Device manager shows Other devices->Unknown device.

When I plug the Cerberus main board in again, it also shows up unknown.

If reinstalling the TinyBoot fixes that, the please show me ASAP. Spinning wheels here with no working hardware. I will be looking through the docs for this…


#4

Got it! Yes, you are correct, and thank-you Architect. Wish I knew how it got blown away.

This is exactly what I did to re-install firmware:

  1. Boot your device into ST Bootloader mode
    Cerb40 - jumper header pin 16 (loader) to pin 1(VCC) and apply the USB
    Cerberus - jumper boot pins next to header number 8, and apply the USB

Windows should show the device as ST Bootloader. If it doesn’t you may have other issues.

  1. Erase the part and load TinyBoot
    Run the DFU Tester.exe program from the programs(x86)/STMicroelectronics/software/DfuSe/BIN/STDFUTest.exe
  • click Protocol tab at the top
  • click Create from Map
  • click Erase
  • click Load DFU file
    C:\ProgramFiles(x86)\GHI Electronics\GHI OSH NetMF v4.2\FEZ Cerb Family\Firmware\TinyBooter_4_2_5_0.dfu
  • click the “Download” radio button
  • click GO.
    Reboot the part. Should ping TinyBooter.
  1. Install TinyClr
    Run the .Net Micro Framework Deployment Tool.exe (MFDeploy.exe)
    load the image file from: C:\Program Files (x86)\GHI Electronics\GHI OSHW NETMF v4.2 SDK\FEZ Cerb Family\Firmware\Non Ethernet\Firmware.hex
  • click Deploy.

Should ping with TinyCLR.

Done. Now watch me blow it away again…


TinyCLR on cerb40 II?
#5

I can’t say why it happened, but reloading always helps. I wish there is a way to nail down that issue. Hydra has similar issue when it needs reloading from time to time.


#6

Could it perhaps be something in the application itself that somehow manages to overwrite a fuse setting or something? It sounds to me like in this case it was a reproducible situation… two Cerb40 boards both got bricked when the same application was loaded. Maybe the source code of the application warrants a close inspection to try and get to the bottom of what might be causing this.


#7

I recently bought a Cerbuino Bee to try out as an upgrade from the Panda II, and had the same problem discussed here.

Specifically, a new generic Gadgeteer project created in VS 2010 ( C# ) would not go into debug. Neither could other code that I found on the Forum.

I then followed the steps covered by Jockey4her to download a new loader and then the firmware, and now the generic project did go into debug.

However, when I started including my own code to the project, the Cerbuino became unresponsive. This echoes what KiwiSaner reported.

I then repeated the steps to download the loader and the firmware, but now I couldn’t load the firmware. The GHI Config tool indicated “loder mode”, and rebooting the board as instructed by the tool did not change this. In fact, if I switched to the Firmware tab and then rebooted, the loader was now shown as erased!

After a few more tries, I gave up and sent the board back to GHI. I included printouts of screen captures of the various steps, and asked for either a fix or a refund. If this problem was due to a dumb mistake on my part, so much the better if it gets the problem solved.