Hello, I’m using preview2 with the last network sample version I could find) and I am able to join the network, but fails to get an IP from DHCP.
Is there a command to force the retry to get an IP ?
also, sometimes, the program gives an exception “Buffer size exceeded max”. but when running step by step, I was not able to find where the exception occurs. any ideas ?
last thing, at this point, it is possible to create a WLAN (not join an existing WLAN) ?
Great work anyway. nice device 
If it fails to get an IP, I would check into your DHCP server. There’s no command in the driver we’ve written to force retry and I didn’t see one in the module’s API either, though feel free to take a look at https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/69/bf/26/08/53/62/49/af/DM00329655/files/DM00329655.pdf/jcr:content/translations/en.DM00329655.pdf
If you see the buffer size error again, see if anything interesting appears in the Output Window. Does it seem to occur at the start of the program, when downloading some data, or at another point?
I don’t think the module supports creating its own access point either.
hello John,
Thanks for your reply.
The only thing I found in the doc related to DHCP Client is is default to autoip (value 2 of variable ip_use_dhcpc), and this is what that seems to happen, the IP it shows is an auto configured IP (that is if my understanding of the different messages is correct).
I tried on 3 different VLAN and all them have DHCP enabled.
related to the buffer size, it happens at the very beginning.
here is a part of the debugger output (sorry for French language but the interesting part are not in French anyway) :
Le thread ‘’ (0x2) s’est arrêté avec le code 0 (0x0).
#### Exception System.Exception - 0x00000000 (3) ####
#### Message: Buffer size exceeded max.
#### GHIElectronics.TinyCLR.Drivers.STMicroelectronics.SPWF04Sx.Helpers.GrowableBuffer::EnsureSize [IP: 001f] ####
#### GHIElectronics.TinyCLR.Drivers.STMicroelectronics.SPWF04Sx.SPWF04SxInterface::Process [IP: 0120] ####
Une exception non gérée du type ‘System.Exception’ s’est produite dans GHIElectronics.TinyCLR.Drivers.STMicroelectronics.SPWF04Sx.dll
Informations supplémentaires : Buffer size exceeded max.
and third point: the module does indeed support to be an access point : miniAP. This is value 3 of variable wifi_mode.
I’m relatively new to github, is there any documentation to use in order to clone the source and try on my own ?
thanks !
Do you know if you’re running the latest Wi-Fi firmware?
We don’t have any documentation on using git ourselves, but Git - Book is always a good reference.
If you only want to clone the source to play around with on your own, GitHub has a download button on each repo that lets you download a ZIP:
hello John,
I haven’t updated the firmware of the WIFI, only the FEZ itself. I received the board last week from Mouser, so I’m not sure what version it is supposed to have.
I saw that the WIFI module is now end of life. so I will stay tuned on GHI steps on that matter.
About GitHub, I was able to download the repos (tinyclr-ports, tinyclr-samples and tiniclr-drivers) but I was expecting a full repo that has all the components in a single repo. At this moment I am not able to run my project and includes the drivers (it still use nuget).
I will read carefully the link you send and play around that,
thanks !
We do recommend updating the firmware on the Wi-Fi module, http://docs.ghielectronics.com/hardware/components/spwf04sa.html has some steps on how to do that.
So to work with the source for the Wi-Fi driver, you only need the drivers repo. You can just add the SPWF04Sx project to your own solution, then add a reference to that project in your project (you may need to uninstall then reinstall the NuGet packages). Alternatively, just take the source files for the Wi-Fi and add them to your project.
Just want to set expectations here… but I am an outsider, I don’t represent GHI…
Just because a part becomes EOL, does not mean GHI will do anything about current inventory or already produced units. Those are what they are, they’re complete and in the market. They may also have completed a purchase of more inventory of wifi modules waiting to be assembled, which again doesn’t change anything for anyone. GHI have shown over the years that they stand behind their products as long as possible, longer than many others, and so I expect you will see continuing support for Fez devices with that wifi module on in TinyCLR for some time to come, at a software level. You as a new owner just need to realise that sometime in the future GHI will release a new product with a new wifi module, that will be different to your current one. No problem really, but there will be nothing for you or GHI to do, no “steps on that matter”
To add wifi access point (open), here is the portion of code to add to SPWF04SxInterface.cs:
The default IP is 192.168.5.1, when connecting to this IP, will show an web UI that allow to define all network wifi settings.
public void CreateOpenMiniAP(string ssid)
{
this.DisableRadio();
var cmd = this.GetCommand()
.AddParameter("wifi_mode")
.AddParameter("3")
.Finalize(SPWF04SxCommandIds.SCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
cmd = this.GetCommand()
.AddParameter("wifi_priv_mode")
.AddParameter("0")
.Finalize(SPWF04SxCommandIds.SCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
cmd = this.GetCommand()
.AddParameter("wifi_auth_type")
.AddParameter("0")
.Finalize(SPWF04SxCommandIds.SCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
cmd = this.GetCommand()
.AddParameter("wifi_channelnum")
.AddParameter("1")
.Finalize(SPWF04SxCommandIds.SCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
cmd = this.GetCommand()
.AddParameter("ip_ipaddr")
.AddParameter("192.168.5.1")
.Finalize(SPWF04SxCommandIds.SCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
cmd = this.GetCommand()
.AddParameter(ssid)
.Finalize(SPWF04SxCommandIds.SSIDTXT);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
this.EnableRadio();
cmd = this.GetCommand()
.Finalize(SPWF04SxCommandIds.WCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
this.FinishCommand(cmd);
}hello John,
I need your opinion, I started to write a few queries to get variables value (like the MAC or the serial number).
please let me know what you think of the 2 functions below.
basically I was thinking of 3 options :
create a function per variable
or create a generic function that cover all variable and return an array
or alternatively, return only the value of the variable we pass in parameters. (we have to keep in mind some are int and some are strings
what would you think ?
thanks !
public string QueryMACAddr()
{
var cmd = this.GetCommand()
.AddParameter(“nv_wifi_macaddr”)
.Finalize(SPWF04SxCommandIds.GCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
var str = string.Empty;
while (cmd.ReadString() is var s && s != string.Empty)
str += s;
this.FinishCommand(cmd);
return str.TrimEnd('\r', '\n'); ;
}
public string QuerySerialNumber()
{
var cmd = this.GetCommand()
.AddParameter("nv_serial")
.Finalize(SPWF04SxCommandIds.GCFG);
this.EnqueueCommand(cmd);
var result = cmd.ReadString().Split('=');
//string serialnb = result[1];
//serialnb = serialnb.TrimEnd('\r', '\n');
cmd.ReadBuffer();
this.FinishCommand(cmd);
return result[1].TrimEnd('\r', '\n'); ;
}So if I were adding this I’d probably do it like so:
public delegate void CommandCallback(SPWF04SxCommand cmd);
public void ReadConfiguration(string variable, CommandCallback callback) {
var cmd = this.GetCommand()
.AddParameter(variable)
.Finalize(SPWF04SxCommandIds.GCFG);
this.EnqueueCommand(cmd);
callback.Invoke(cmd);
this.FinishCommand(cmd);
}
public string ReadSerialNumber() {
var res = "";
this.ReadConfiguration("nv_serial", cmd => {
res = cmd.ReadString();
cmd.ReadBuffer();
});
return res.Split('=')[1].TrimEnd('\r', '\n');
}
I’ve not actually ran the above code, but it’s the rough idea. If we had generics the delegate could be generic over the return type and I could return directly instead of using shared state like I do.
I give a new try with TinyClr-Drivers (lastest changes) and all seems working very well with new firmware (171117-0328fe3-SPWF04S) !
Good job as usual at GHI. Now I can reach my http site.
Next step is to try httpS.
@John_Brochue:
Few question about https:
Hi, I can only say how it is in NetMF. The certificate in the resources had to have the extension .cer and the root certificate had to be used.
Kind regards
RoSchmi
Our driver currently only supports the DER format (which is usually found on Windows with a crt extension). The Wi-Fi module itself supports PEM, but our driver does not.
In the common case you only need to load the root certificate (the module also supports client authentication, but our driver currently does not). For example, if you were trying to connect to our main site, the SSL cert you’d want from our chain is DigiCert Global Root CA with a SHA1 fingerprint of A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36.
The following may be useful to you.
@John_Brochue thank you for this.
I have implemented this code and apart from having to change void to string in the declaration of ReadSerialNumber() it works.
Thanks for the catch, I updated the snippet
It’s working ! I can now get https on few site. TinyClr can now be tagged ‘IoT’ ! 
I confirm that UC5550 Wifi is working in SSL using root certificate after fw update.
With preview3 in release notes:
SPWF04Sx Wi-Fi on the FEZ does not work unless PA0 is manually set low before initialization
are these lines correct (I can’t join network) ?
var _pa0 = cont.OpenPin(FEZ.GpioPin.A0);
_pa0.SetDriveMode(GpioPinDriveMode.Output);
_pa0.Write(GpioPinValue.Low);
yes, or
var _pa0 = cont.OpenPin(FEZ.GpioPin.A0);
_pa0.SetDriveMode(GpioPinDriveMode.InputPullDown);
Can’t join network should be a different thing.