I've done it now -- can't reset

Archive
1

I’m a software guy by vocation.

My first inclination with this new board was to interface with a colorimeter via I2C. The colorimeter has a number of registers that must be interacted with. I debugged the class I had written and knew there was an exception in it.

I decided to go ahead and deploy it so I could see how MF would respond to an unhandled exception.

The result was, MF responds to the exception with “waiting for debug commands…” or shows the hard error display.

I’ve tried every combination I know to get either VS2010 or MFDeploy to interact with the device so I could
erase the program and put something minimal on the Spider. I’ve reset the board more than 100 times hoping to catch it at the right point – no joy.

There must be an alternative. Can you help?

(And let this be a warning to others – catch those exceptions!)

2

That is not really possible so it is a coincidence I believe.

Unplug all modules but only keep the red one. Now connect to a PC:

  1. windows detects it? What do you see in device manager?
  2. MFDeploy detects it? What name? “EMX_Gadgeteer”?
  3. MFDeploy can ping it? What do you see back? “TinyCLR” or “TinyBooter”?
3

Gus,

Windows detects it.
MF Deploy sees it.
MF Deploy cannot ping it. Returns message of no response from device.
Attempting to deploy returns the same message with MFDeploy. With VS2010, it just hangs.

Unplugging modules did not help. I tried all of those combinations.

I rebooted the PC as well. Everything to get its attention including disconnecting the USB.

What makes you say it is not really possible?

4

Glenn,

Gus says it isn’t possible because an exception shouldn’t hang the board.

I suspect that your application is in a very tight loop, due to the exception, and that is using all the CPU time, leaving non for the USB interface.

You will probably need to start up in “safe” mode, but I don’t know how that is done on the Gadgeteer. Does it have a “Loader” button?

5

Errol,

I don’t know of any loader button.

The fact that the message “waiting for debug commands…” appears when the exception happens tells me that something dodgy is going on after the exception as opposed to a loop.

Regards

Glenn

6

The loader “button” is in the form of a DIP switch (see instructions)… you can put it in this mode and reload the firmware and clear your code.

7

Glenn,

I just looked at the board and schematic.

There are 4 switches. Switch number 1 and number 3 to “On”. Press and release Reset.

This will force the board to stay in bootloader mode. MF Deploy can then be used to erase the user application. If you erase all then you will have to re-flash GHI firmware. It is not necessary to erase all…

Remember to set all the switches back to Off and reset. Should be back to normal.

8

Thanks, Errol. I’ll give it a go after work.

Regards,

Glenn

9

Thank you Errol and all! Worked like a charm!

What documentation is that in? I missed it somehow.

Regards,

Glenn

10

The switch configurations are explained on the card found in FEZ Spider’s bag.
And if, at some point, you are not sure what is happening with the board (rarely needed for beginners) you can use FEZ Spider updater application (included in the installed SDK) that reflashes the firmware and erases the user application.
Or you can use the more advanced troubleshooting processes using MFDeploy and accessing GHI boot loader:
[url]http://wiki.tinyclr.com/index.php?title=Firmware_Update_EMX[/url]