Spider and WiFi_RS21 - Strange behaviour

Archive
21

So, after MUCH trial and error I finally got to see a com port from the Spider (Com18). Once I’d seen this I ran the GHI FEX Mainboard update tool again and on my second attempt it successfully updated.

I then loaded VS2010 and create a new 4.1 project with no additional code and was able to deploy it back to the Spider.

HURRAY !!!

That was a rediculous mess to have to sort out and I can’t believe things appear to be back to normal. Is there a set of instructions (as I don’t think I could reproduce the steps I’ve just followed) for getting a Spider back from the point to useless to operational again that I could follow if that occurs again?

I need some time away from this device now and will get back to it in a da or twos time. Thanks again for those who chipped in with advice or suggestions. At least I didn’t have to return it.

Jason.

22

great news you haven’t got a fried board.

Fundamentally it just seems like something corrupted your firmware or made the debugger not be able to expose itself to the PC; whether that was your code or not I guess we won’t know.

One thing someone here always suggests (I think it was Mike) is to make sure you have a gate that allows your code to stay in a wait state until something happens, that gives the debugger plenty of time to establish connection before important stuff like intiialising the WiFi occurs. That could be a button press, or a delay of some length that’s suitable.

1 Like
23

+1 on Brett’s comment. I usually try to put startup blocking items (like some WS_RS21 actions) in a timer that is only a few seconds, and then disable it.