Freezing Cobra II - Wifi Scan

Archive
1

I’ve got a Cobra II board and I’ve been working on some comms software transmitting over the wifi.

Recently the processing would occasionally lock up, and that would mean all threads would freeze. I could get past this by going to Visual Studio, perfoming a ‘break all’ and then a ‘continue’, after which the processing would continue.

I searched around and found a thread that said there was a bug with Visual Studio 1012 debugging so I ignored these.

Earlier today however, I noticed that the board seemed to lock up even when I wasn’t debugging and now the board is constantly locking up when ever it performs a Wifi.Scan instruction. In addition I cannot perform a ‘break all’ when this happens.

Has anyone experienced this type of problem? It seems to me that this is a problem with the board’s wifi chip but I thought I would ask the question before writing off the hardware.

2

@ Slade - I was unable to reproduce your issue using the following code:

public partial class Program
    {
        // This method is run when the mainboard is powered up or reset.
        GHINET.WiFiRS9110 wifi;

        void ProgramStarted()
        {
            Debug.Print("Program Started");
            wifi = new GHINET.WiFiRS9110(SPI.SPI_module.SPI2, Pin.P1_10, Pin.P2_11, Pin.P1_9, 4000);
            
            Debug.Print("Opening WiFi");
            if (!wifi.IsOpen)
                wifi.Open();

            Debug.Print("Enabling DHCP");
            if (!wifi.NetworkInterface.IsDhcpEnabled)
                wifi.NetworkInterface.EnableDhcp();

            Debug.Print("Assign to TCP/IP stack");
            GHINET.NetworkInterfaceExtension.AssignNetworkingStackTo(wifi);

            Debug.Print("Scanning networks");
            GHINET.WiFiNetworkInfo[] scanResults = wifi.Scan();

            Debug.Print("Sorting " + scanResults.Length + " results");
            foreach (GHINET.WiFiNetworkInfo info in scanResults)
                Debug.Print(info.SSID + " found with " + info.RSSI + "db ");

            //wifi.Join(scanResults[myNetwork], "myPass");
        }
    }

Outputs:

[quote=“FEZCobraII”]Using mainboard GHI Electronics FEZCobra II version 1.0
Program Started
Opening WiFi
RS9110 firmware version Number is 4.4.5
RS9110 driver version Number is 4.4.5
Enabling DHCP
Assign to TCP/IP stack
Scanning networks
Sorting 2 results
GHI Developers G found with 60db
GHI Production found with 70db [/quote]

If you are still having issues, have you tried flashing from Tinybooter on up to see if this cures the issue?

3

Hi James, thanks for your reply.

I wouldn’t expect you to be able to reproduce the problem because my code has been working too. This situation seems to have got worse over time. It started intermittently and now seems to be constant.

I’ll try re-flashing tonight to see if it fixes it.

4

I tried re-flashing the tinybooter and tinyCLR but unfortunately the problem persists.

I think the wifi module is no longer functioning.

5

@ Slade - Does the module respond otherwise? Are the firmware and driver version numbers correctly output on init?

6

James, the rest of the board works fine. It just hangs on a wifi network scan.

Yes, I get the same firmware and driver messages as you did. Both at 4.4.5 but nothing after that and I have a debug print directly before and after the scan.

It’s a bit frustrating but I can use the board to test other things. I have some work I need to do with a CP7 screen so it will be good for that.

7

Ok, I have an update.

I tried running the software on a new Cobra II board and I got the same problem so it must be something to do with the software.

I then tried to do a ‘release’ version and it just compile with the following error:

Link failure: some assembly references cannot be resolved!!

The assembly it is trying to resolve is one of my own which is included as part of the solution.

I’m not sure if this is related but I will soldier on to see if I can get to the bottom of this.

8

I seemed to have solved the deployment problem now but I’m still left with the original problem.

9

I think I’ve found a solution to this. I’m not sure what exactly was causing the problem but the project is quite advanced and uses a flash module.

I had recently taken the main program code and put it in it’s own class/assembly so that I could re-use it in many projects. I think this new class was initialising everything in the wrong order. It was failing when scanning for networks but I think this is the first time that the CPU is free to process other threads so it may not have been the wifi that caused the problem.

I reorganised the processing order and so far, so good.