Network samples?

Is it possible to have some clue to start network with FEZ ? I think I must begin connecting FEZ on Wifi, but can’t find a way to do it.

1 Like

Funny, just looking for the same!

1 Like

I am also looking for guidance in this area!

1 Like

We have more complete docs in progress, but the below gist shows various uses of the APIs found in the GHIElectronics.TinyCLR.Networking.SPWF04Sx, GHIElectronics.TinyCLR.Networking, and GHIElectronics.TinyCLR.Networking.Http libraries.

4 Likes

Thanks John for this precious gist.

1 Like

I’ve succeeded to set time of FEZ with Ntp. :sunglasses:

But a lot of times, I’ve errors:

    #### Exception System.InvalidOperationException - 0x00000000 (4) ####
    #### Message: Unexpected payload.
    #### GHIElectronics.TinyCLR.Networking.SPWF04Sx.SPWF04SxInterface::Process [IP: 016e] ####
Une exception non gérée du type 'System.InvalidOperationException' s'est produite dans GHIElectronics.TinyCLR.Networking.SPWF04Sx.dll
Informations supplémentaires : Unexpected payload.

Or

Press button to turn wifi on...
    #### Exception System.Exception - 0x00000000 (4) ####
    #### Message: Buffer size exceeded max.
    #### GHIElectronics.TinyCLR.Networking.SPWF04Sx.Helpers.GrowableBuffer::EnsureSize [IP: 001f] ####
    #### GHIElectronics.TinyCLR.Networking.SPWF04Sx.SPWF04SxInterface::Process [IP: 0120] ####
Une exception non gérée du type 'System.Exception' s'est produite dans GHIElectronics.TinyCLR.Networking.SPWF04Sx.dll
Informations supplémentaires : Buffer size exceeded max.

May be it is linked with loses writes bug ?

Hard to say the exact cause. Can you post the exact requests you’re sending that trigger the errors so we can try it here?

1 Like

It seems that payload error is linked to too short time between turn on wifi and joinNetwork. I put a Thread.Sleep(2000), and payload seems have gone.
But Buffer size error continues to appear randomly.

As previously said, I can update time of FEZ correctly but can’t get a web page with TestHttp (for now I Don’t try https). Code is below.

I get this:

## Start test...
Failed allocation for 52 blocks, 832 bytes

    #### Exception System.Exception - 0x00000000 (1) ####
    #### Message: Request failed
    #### GHIElectronics.TinyCLR.Networking.SPWF04Sx.SPWF04SxInterface::GHIElectronics.TinyCLR.Net.NetworkInterface.IDnsProvider.GetHostByName [IP: 004f] ####
    #### System.Net.Dns::GetHostEntry [IP: 000b] ####
    #### System.Net.HttpWebRequest::EstablishConnection [IP: 00e4] ####
    #### System.Net.HttpWebRequest::SubmitRequest [IP: 0019] ####
    #### System.Net.HttpWebRequest::GetResponse [IP: 000c] ####
    #### testWifi.App::TestHttp [IP: 0049] ####
    #### testWifi.App::Init [IP: 00e7] ####
    #### testWifi.App::.ctor [IP: 000a] ####
    #### testWifi.Program::Main [IP: 0005] ####
    #### Exception System.Net.WebException - 0x00000000 (1) ####
    #### Message: 
    #### System.Net.HttpWebRequest::GetResponse [IP: 00d3] ####
    #### testWifi.App::TestHttp [IP: 0049] ####
    #### testWifi.App::Init [IP: 00e7] ####
    #### testWifi.App::.ctor [IP: 000a] ####
    #### testWifi.Program::Main [IP: 0005] ####
Exception levée : 'System.Net.WebException' dans GHIElectronics.TinyCLR.Networking.Http.dll

WIND: SocketClosed 0:0

is it possible that the http response is greater than the memory in the Fez?

Oh… error message is a dns failure. Is dns server set correctly?

Is there a way to get dns info from code ?

I have to admit that I have not used TInyClr yet…

When getting this error message I would check the status of the Wifi connection. The DNS address is usually set upon Wifi connection. The Wifi object should have info about the ip and dns ip addresses.

Regarding too short of a wait, yes, you need to make sure everything is ready and working before trying to join a network or making a request. You can do this by listening to the IndicationReceived event as you do and setting your own flags once you receive events like WiFiUp. You can get a feel of what events to expect by just printing out every indication received and being liberal with how long you wait between button presses.

To get System.Net.Dns to work with this Wi-Fi module, we had to cheat a little since it doesn’t expose a low-level network driver. We make a quick HTTP request to the given URL using the built-in HTTP stack and extract the IP address from that. It’s not ideal but there was no immediate way around it that we could see (beyond attempting to query some potential DNS servers exposed over HTTP).

What I’d do next is use the HTTP commands built into the WiFi module, not the .NET HTTP stack, just to eliminate one potential issue for now. Use the SendHttpGet, SentHttpPost, and ReadHttpResponse methods to do so, they remove a lot of the overhead that comes with using the .NET HTTP stack. Their use starts at line 114 in the gist I sent.

I think it is dns related too: when I try var resp=Dns.GetHostEntry("192.168.1.2");, an exception is raised too. But I can’t find a way to ensure that dns are correctly set.

It is clear that to get reply I must wait for WifiUp AND _wifi.State == SPWF04SxWiFiState.ReadyToTransmit. But buffer error continues to appear at boottime randomly. Must I wait Something else before to call TurnOn() ?

Bad guy ! :wink:

That is what I’m trying now.

var code = _wifi.SendHttpGet("www.ghielectronics.com", "/dummy.txt", 80, SPWF04SxConnectionSecurityType.None);

If I want to get an unexisting doc, an exception is raised:

 #### Exception System.Exception - 0x00000000 (1) ####
    #### Message: Request failed: 404

    #### GHIElectronics.TinyCLR.Networking.SPWF04Sx.SPWF04SxInterface::SendHttpGet [IP: 00a7] ####
    #### testWifi.App::Init [IP: 00ed] ####
    #### testWifi.App::.ctor [IP: 000a] ####
    #### testWifi.Program::Main [IP: 0005] ####
Exception levée : 'System.Exception' dans GHIElectronics.TinyCLR.Networking.SPWF04Sx.dll
Request failed: 404

I think it is not what it should be: code must be 404, I think an exception shouldn’t be raised. But the good news is that module seems to reach internet !

If I try an existing doc:

var code = _wifi.SendHttpGet("www.bauland.fr", "/robots.txt", 80, SPWF04SxConnectionSecurityType.None);

I have an exception raised too: (but without error code). Could it be an memory error as @Mike suggest ?

## Start test...
    #### Exception System.Exception - 0x00000000 (1) ####
    #### Message: Request failed: 
    #### GHIElectronics.TinyCLR.Networking.SPWF04Sx.SPWF04SxInterface::SendHttpGet [IP: 00a7] ####
    #### testWifi.App::Init [IP: 00fd] ####
    #### testWifi.App::.ctor [IP: 000a] ####
    #### testWifi.Program::Main [IP: 0005] ####
Exception levée : 'System.Exception' dans GHIElectronics.TinyCLR.Networking.SPWF04Sx.dll
Request failed: 

In the startup messages, one of them gives basic module info like version. What version do you have?

If memory is causing the issue, you’ll get an OutOfMemoryException. For a simple page like a robots.txt that shouldn’t be an issue.

That’s what I obtain at startup:

Turn wifi on...
WIND: WiFiSignalOk 11
WIND: PowerOn 117016-ffd9c599-PWF004
WIND: Copyright SPWWF0SA
WIND: ConsoleActive 

I suppose that version is in PowerOn message.

Here’s a log from my test run:

WIND: PowerOn 171117-0328fe3-SPWF04S
WIND: Copyright SPWF04SA
WIND: WatchdogRunning 20
WIND: ConsoleActive 
WIND: WiFiHardwareStarted 
WIND: WiFiScanning 
WIND: WiFiScan 00
WIND: WiFiJoin [MAC]
WIND: WiFiAssociationSuccessful [SSID]
WIND: WpaHandshakeComplete 
WIND: WiFiUp [IPv6]
WIND: WiFiUp [IPv4]
WIND: NtpServerDelivery 2018.8.10:5:19.1.45

PowerOn is indeed the version and it looks like yours is out of date, there’s some weird corruption in it and the copyright. We don’t have built in support for updates at the moment so you’ll need to follow the instructions from ST.

It seems to be different way to update Firmware:

  • FOTA: but when I’ve problem to connect to server I think I must forget this way.
  • UART: I Don’t know if it can be but fw hex must be in resource file ?
  • SWD: I Don’t understand.

So if you can provide me some tips, I would appreciate. I’m a little lost.

I’d recommend going the UART way. The four-pin header near the Wi-Fi module and USB connector exposes the UART pins for the Wi-Fi module itself. That module has an ST processor inside that you can connect to using the various ST DFU tools to erase the chip and load the firmware. The firmware to load should be available in the download package from ST on the module page.

I don’t have USB to UART here. I give a try when go back home.

Just to don’t kill the board, is my schematic ok ?