WiFiRS21 Constructor never returns

I’ve just powered up my small test system which was fine until a few hours ago when I shut it all off.

Now I’m unable to get test apps to do anything, they all hang and the hang can be traced to the constructor of the WiFiRS21 class. If I deploy and put a break on the call to the constructor its fine, debugger is fine, but once the constructor is invoked it never returns and the debugger eventually claims “Program Started” is taking > 10 secs.

This isn’t quite true because until WiFiRS21 constructor returns, ProgramStarted will not even get called.

The device is connected to Socket 1 of a Raptor.

If I erase the app then power off/on the system, it comes up and waits for debug commands (it has a display attached). At this time the WiFi green light is off. If I then deploy and debug via VS 2013, the WiFi light comes on but the constructor never returns.

What’s happened here?

I’ve erased the app several times and run a test app that hasn’t changed in days and last ran fine yesterday.

Everything is sitting in a safe place and has been fine for past few days, there is nobody else here to mess with it, there’s been nothing untoward at all, no power outages, PC crahses etc - nothing.

I also changed the cable, has no effect on observed symptoms…

Thanks

Korp.

PS: Also just to be very clear, I’m fully aware that connecting/disconnecting must be done with no power attached.

Slightly more testing - this time I dug out another recent test App.

The call to WiFiRS9110 hangs with args:

Initing WiFiRS9110: SPI Module: 1, Select: 37, Interrupt: 32, Reset: 7

This debug output is displayed in the VS Output window.

Also, when the green LED on the device comes on, it stays on, there’s no flicker, or transient on/off - it comes on and stays that way until I shut off power.

It is SPI 2, confusingly they number the enums starting at zero so enum value 1 is module 2. Besides, all test/demo apps that used to do something now simply freeze in the constructor.

@ KorporalKernel - Get the Gadgeteer source for the module and compile into your program. Then you can single step into the driver and see exactly where the constructor is hanging.

I’ve had this happen once before and found that the module had died on me.

That might be intriguing, but it probably won’t help me get it running. I don’t see that there are any kinds of actions one can perform on this device other that power it on/off and interact with it through a mainboard.

If there are diagnostic programs I can run or firmware reloads then fine, but at this stage the device appears to be defective in the sense the end-user can’t do much.

I’ve contacted GHI to see about getting this replaced, I am curious though to know exactly what the failure is and if there is a pattern in such failures, like is it loss of firmware or some passive component that’s failed etc.

Korp.

Indeed replaced cable, no observable difference - out of curiosity has anyone else here had the WiFiRS21 module fail like this? is this uncommon?

Korp.

You are curious as to the exact problem but are reluctant to do a little more debugging? Maybe there is something that can be done to revive your board without sending it back.

Well I’m only reluctant because I don’t see what actions I [em]could [/em]conceivably take even if I do learn more.

I can’t replace physical parts obviously, I’ve replaced the cable already so that’s out.

What’s left as possible options here? if there are options then perhaps I should simply try them without any additional debugging, for example can one refresh firmware for example?

Korp.

@ KorporalKernel - The only way I could answer your questions would be to look at the Gadgeteer code and the GHI SDK documentation, which I am reluctant to do. :frowning: :frowning:

[quote=“KorporalKernel”]Well I’m only reluctant because I don’t see what actions I [em]could [/em]conceivably take even if I do learn more.

What’s left as possible options here? if there are options then perhaps I should simply try them without any additional debugging, for example can one refresh firmware for example?[/quote]

What Mike is saying is that you pull the WifiRS21 driver source down and insert it into your project instead of using the compiled driver provided by the SDK then you will be able to step through the constructor and probably learn the source of your problem. There’s likely not a problem with your hardware.

I’ve already verified that the hang occurs within the constructor for the WiFiRS9110 class, I have no idea where the source for [em]that [/em]class is - codeplex, gihub, bitbucket…

Also I’ve no idea what it takes to compile that class if I do find, surely its part of some class library assembly and I’ll need whatever dependencies that library has and so on…?

But nobody seems to grasp - if its possible that this isn’t hardware and there is some other way to remedy this, what might that be? surely there are only one or two things I could do so I’m willing to simply try those without any need to debug anything.

Is there any documentation that discusses how to make non-hardware adjustments to this module?

Thanks,

Korp.

[quote=“KorporalKernel”]
I’ve already verified that the hang occurs within the constructor for the WiFiRS9110 class, I have no idea where the source for [em]that [/em]class is - codeplex, gihub, bitbucket…[/quote]

Sorry, I don’t have time for the long answer right now but if you look for the “Source Code” link on this page you will be able to located the driver code. Inspecting the constructor should give you some idea what it is doing and maybe give you some other ideas. If someone else doesn’t sooner, I’ll try to give you some direction this evening on how to take that code and insert it into your project so you can step through it in the debugger.

https://www.ghielectronics.com/support/gadgeteer

@ KorporalKernel - if you are looking for the Gadgeteer source code I suggest you look on the GHI support page for Gadgeteer.

@ ianlee74 - The only source there is for the class WiFiRS21, no use to me because I know that the hang occurs in the constructor for WiFiRS9110 a class in assembly GHI.Networking - which (it seems) isnt public code.

Stepping through that class might be instructive but I don’t have it (this is why I was referring to the project’s (GHI.Networking assembly) and all of it’s dependencies, basically we’d need to be able to locally build the GHI.Networking.dll but we can’t - so far as I can see.

Thanks,

Korp.

PS: lets say we did find something noteworthy while stepping, what kinds of actions could we conceivably take with the module?

[quote=“KorporalKernel”]
@ ianlee74 - The only source there is for the class WiFiRS21, no use to me because I know that the hang occurs in the constructor for WiFiRS9110 a class in assembly GHI.Networking - which (it seems) isnt public code.[/quote]

Wow… I didn’t catch that you had jumped from WifiRS21 to WifiRS9110. Sorry. You’re correct that source code isn’t available anywhere that I know of. So, which module are you using? I think you might want to post some code.

@ KorporalKernel - If you let the board sit in the constructor for a few minutes, do you get any exceptions?

@ KorporalKernel -
did you read this thread? Seems to be the same problem.
https://www.ghielectronics.com/community/forum/topic?id=19880&page=1
As far as I know the driver for the WiFiRS21 Module is not open source. It’s private property of GHI and only GHI could step through the code.

@ John - No, no exceptions arise even when left as-is for up to 10 minutes. I did do some exploratory debugging though, here’s an interesting stack trace - I ran the WiFiRS9110 constructor call on a separate thread to avoid blocking the system then I break in the main thread (the one calling ‘Main’), at that here’s what I see when I jump to the stack for the thread doing the wifi init:

This may mean something to you guys, looks like it does something with MAC Address and part of that entails waiting in an auto reset event…

Korp

Here’s a better close up of the stack trace: