I keep reading about issues effecting the official WiFi shield after the firmware has been upgraded.
I thought I had upgraded the firmware on my own shield but I am not experiencing the issues being reported. However, when I call
Serial.println( WiFi.FirmwareVersion());
I get V1.0.0
Just wondering whether someone that has performed the firmware upgrade could run the same command and let me know the result they get.
Thanks in advance.
I Get
error: 'class WiFiClass' has no member named 'FirmwareVersion'
Im using 1.0.5 on a Arduino UNO R3 and official wifi shield R3...
Mirroring kikiruiz's results. Same hardware and versions.
I thought you had to buy an arduino brand FTDI cable to read version off the shield with. That's what I read from an email reply by an arduino team engineer. Maybe that undocumented function is not working yet. See here:
There is no mention of such version function call.
My main concern is where IS the original R3 firmware?! That seems to work best for me and I just had to flash it with more recent stuff 8)
Just a clue from a firmware downgrade I did moment ago:
"Reading Bootloader version............. PASS 1.0.2"
Maybe the most recent version is 1.0.2?
FYI, I had some problem with the most recent firmware and downgraded to the firmware included in arduino IDE 1.0.3 (2012-12-10 date code on files) and it seems to work with library version (2013-01-13). I didn't try the 2012-12-10 library.
Thanks for trying and I must apologies for providing you all with duff information. In my haste, I got the capitalisation wrong 
The call should have been
Serial.println(WiFi.firmwareVersion());
And I would still appreciate someone who has upgraded, trying it out.
The .firmwareVersion() method is documented here. See line #34
https://github.com/arduino/Arduino/blob/master/libraries/WiFi/WiFi.h
The "Reading Bootloader version............. PASS 1.0.2" is the wrong information.
I wouldn't say this is good documentation:
/*
* Get firmware version
*/
I have two shields. The original R3 returns 1.0.0. The one I flashed with various firmwares from Aduino IDE releases:
Here is what I found inside the elf file of the IDE 1.0.2 12/05/2012 firmware:
Mon Jun 18 07:44:47 2012 (then later) 1.0.0
Return from the call is 1.0.0
Here is what I found inside the elf file of the IDE 1.0.3 12/10/2012 firmware:
Tue Oct 23 08:45:56 2012 (then later) 1.0.0
Return from the call is 1.0.0
This is very bad practice! One should NEVER assign the same version number to different code. A comparison reveals 300K bytes are different so these two firmwares are different!
Firmware in IDE 1.0.4 is identical down to every byte to that in IDE 1.0.3 so I didn't bother to load it. It would yield 1.0.0 on call.
Here is what I found inside the elf file of the IDE 1.0.5 05/17/2013 firmware:
Tue Mar 26 22:09:54 2013 (then later) 1.1.0
Return from the call is 1.1.0
Here is what I found inside a once "latese" firmware on github, the one that fails as web server with iOS devices, apparent the same as released by IDE 1.0.5:
Mar 26 22:09:54 2013 (then later) 1.1.0
I didn't bother to flash with it.
So conclusion: there are three (maybe more if I dig harder) different (real different) firmware versions that can be found online. There are only TWO return values of this useless function call, 1.0.0 for all pre-Arduino IDE 1.0.5 firmware, and 1.1.0 for Arduino IDE 1.0.5 firmware.
Using the correct command I get..
MAC: 0:0:0:0:0:0
WifiVersion:
1.1.0
MattS,
I updated, or thought I did using command prompt on windows, . I did it three or four times with only a warning that the user program and the bootloader overlap. A google search on this yielded a comment that this was only a warning and has no effect.
I used the code from several Adruino WiFI examples to check for existence of shield and check version using variable fv. (WiFi Web Client has this code look for variable fv).
And the result I get is always version 1.0.0.
The sketch I created using this expensive shield attaches to several different wifi networks for readings - I was hoping it would work nonstop, that I could let it run for hours or days, then evaluate the data it collects from the SD card. I was hoping the wifi_dnld.elf and WifiHD.elf updates would permit me to connect to more than about 50 networks before the board seems to fail and the sketch seems to stop after a few error readings.
So, I am also wondering if anyone used the WiFi.firmwareversion() function with correct results after an update.
(I think the reference to 1.0.2 shown during the update process in some of these comments apply to the wifi shield bootloader, not the wifi software version.)
Thanks for your question.
Matthias
This thread is old and things have moved on a little bit.
The current situation (12 /11/2013).
The shield firmware must match the Arduino library code <WiFi.h>
Arduino 1.0.5 should only be used with WiFi shields which return
WiFi.firmwareVersion() == "V1.1.0"
Shields running earlier versions of firmware may report
WiFi.firmwareVersion() == "V1.0.0"
or they may report something different. Behaviour has not been consistent.
I have just completed and documented the upgrade process using Windows.
This is what worked for me, today.
(perhaps one of the mods would like to make it a sticky)
DO NOT USE THE WIFI LIBRARY ON GITHUB
The library and firmware in Github is an earlier development snapshot and is known to be problematic.
To be certain of using the right firmware files,
download the latest stable version of the Arduino application zipfile,
from the Download link at the top of this page.
Having downloaded the Zip file, extract it.
The firmware files are located in a subfolder
\hardware\arduino\firmwares\wifishield\binary
To carry out the upgrade using Windows, you will also need the batchisp.exe command line DFU programming utility,
which is included with Atmel Flip and can be downloaded from
You should not need the JRE or the GUI applications included with Flip,
but it does not hurt to install them.
For this example, assume the Arduino files were extracted into C:\Arduino105 and Flip was installed in C:\Atmel\Flip
The WiFi Shield is fitted to a powered down Arduino Uno, to reduce the risk of ESD damage.
On the PC, open a DOS prompt.
Enter the following commands and leave the DOS window open
path=%path%;c:\atmel\flip
c:
cd \arduino105\hardware\arduino\firmwares\wifishield\binary
You are now ready to upgrade.
Connected your PC to the shield's micro-USB port.
Short the J3 jumper on the WiFi Shield.
Back in the DOS window enter the following command
batchisp.exe -device AT32UC3A1256 -hardware usb -operation erase f memory flash blankcheck loadbuffer wifi_dnld.elf program verify start reset 0
Shield responds with solid Blue LED. Press the shield reset button. Blue LED extinguishes. Unplug the micro-USB cable and plug it back in again.
Back in the DOS window enter the following command
batchisp.exe -device AT32UC3A1256 -hardware usb -operation erase f memory flash blankcheck loadbuffer wifiHD.elf program verify start reset 0
Press the Shield reset button.
Remove the short from J3
Unplug the micro-USB cable
You can test the shield by uploading the following minimal sketch to your Arduino host board
#include <SPI.h>
#include <WiFi.h>void setup(void) {
Serial.begin(9600);
Serial.println("Setup...");Serial.print("Firmware ");
Serial.println(WiFi.firmwareVersion());
}void loop(void) {
Serial.print("Firmware ");
Serial.println(WiFi.firmwareVersion());Serial.println("Scan networks");
uint8_t numNets = WiFi.scanNetworks();for (uint8_t i = 0; i < numNets; i++) {
Serial.print(WiFi.SSID(i));
Serial.print("\t");
Serial.println(WiFi.RSSI(i));
}
Serial.println();
delay(1000);
}
Indeed this thread is old but I still wonder if they fixed the 100-byte limit on wifi packets. I.e. if you client.print() something longer than 100 bytes, nothing is sent. I've stayed with the stock firmware after my bad experiences with the then new firmware and stayed with the github snapshot library without the UDP support, which works stable enough when arduino wifi acts as a server.
MattS-UK,
Have you got a chance to test the 100-byte packet problem with the newest firmware? They were aware of the problem but it fell off their support wagon 
liudr:
Indeed this thread is old but I still wonder if they fixed the 100-byte limit on wifi packets. I.e. if you client.print() something longer than 100 bytes, nothing is sent.
Hi liudr, hope you are keeping well.
Last week I looked into the 90 byte limit on UDP packets, which turned out to be down to an issue deep within the spi_drv code. I left it at that, as I am not in a position to debug the WiFi shield firmware. I will take a guess (is all it is) that a similar issue effects the TCP Socket and the firmware will not have improved the 100 byte limit.
I've stayed with the stock firmware after my bad experiences with the then new firmware and stayed with the github snapshot library without the UDP support, which works stable enough when arduino wifi acts as a server.
The issue with the library on github is, there are two libraries on github and at least one of them does not work reliably with the latest stable Arduino IDE (V1.0.5).
Using the firmware version which ships with the IDE, I have had no issues which were not in the previous versions but I do have UDP working reliably, subject to the 90 byte limit.
Using the WiFi shield for a while has convinced me it is too CPU bound and too poorly behaved to implement the web based GUI I want to implement. I am currently looking at using a Beaglebone Black for my web server. I will have a look at the Yun at some point but not just yet.
Have you got a chance to test the 100-byte packet problem with the newest firmware? They were aware of the problem but it fell off their support wagon
Don't I wish you had not set me that challenge! I started out thinking, 30 minutes, I can knock up a listener application and have the shield try to send a 100 byte packet. Four hours later, I have a new article in my Knowledge base but still haven't tested a 100 byte packet.
Rough notes but you are welcome to take a look.
http://mssystems.emscom.net/helpdesk/knowledgebase.php?article=51
I will do the 100 byte test for you, probably tomorrow, perhaps over the weekend.
The WiFi shield is turning into my own little pandora's box. The more I look into it the more I find wrong and the more I look into it.
Thanks for agreeing to look into the 100-byte issue. I have to put everything through a chopper so the process of sending a long message is segmented in code that deals with chopping. If I had enough memory I would assemble the complete message and write(char*,int) but the message is a bit too long.
My project only uses TCP clients, which is well-behaved. The system can stay on for days and weeks so I'm ok using the shield (expensive$$$). If you want web server or GUI, BBB or RPI will be the way to go. I am not a linux person so I couldn't push far enough even for simple things such as serving up a page with the latest snapped image out of a folder of images (it's the account/group/access stuff). I was able to create daemonize my camera snapshot program but the folder is not accessible by the samba daemon. Good luck to you! RPI forum is pretty good but BB forum is very strangely organized and I seldom got a response.
Turns out the new firmware version has a similar 90 byte limit for TCP as it does for UDP.
WiFiClient.println(a_string_of_90_bytes)
Causes a string of 92 bytes to appear on the wire. The 90 bytes passed to println and the \r\n characters appended by the library.
WiFiClient.println(a_string_of_91_bytes)
Causes no bytes to appear on the wire.
There is also a timing issue to be aware of. Calling WiFiClient.stop() before ~2 seconds after println(a_string_less_than_90_bytes), may cause zero bytes to appear on the wire. The length of the string appears to make no difference to the necessary write delay. I have been running some tests varying packet lengths and write delays;
delay 1500 == consistent failure (100%)
delay 1700 == unreliable failure (~60%)
delay 1900 == dangerously unreliable. Over 1226 connections, 37 packets failed. The failure rate is low enough to appear random.
delay 2000 == 100% reliable so far, I'm up to about 500 packets.
Matt,
Very interesting results. I will need to look at my code to see where I have made any type of delay (don't think I did but I have an old version of firmware and library).
What do you think? The arduino team just ignored the 90-byte or 100-byte problem or not aware enough (just the one program is aware instead of the whole team)?
OK, after checking, I wait for the server to respond before closing the connection with client.stop() so the delay is variable. I don't think it was over 2 seconds though. I'll add debug info so I can get back to you regarding the delay between last client.print and client.stop.
liudr:
What do you think? The arduino team just ignored the 90-byte or 100-byte problem or not aware enough (just the one program is aware instead of the whole team)?
I will tell you what I think. I suspect whoever was responsible for the Shield's library spent too much time worrying about HTTP and not enough time thinking about the TCP protocol which underlies it. The 90 byte limit is a bottleneck in the SPI bus. It is not a huge limitation, of itself. Just write chunks of 90 bytes as fast as you can to the bus and let the Shield get on with sending it.
I am more concerned with the socket management being decoupled. Not having access to a socket ID, is a huge limitation. Not being able to signal connection close on demand is a huge limitation. A socket signalling close when a connection is initiated with a different socket...Seems very odd to me!
On the whole, I think the Shield is suitable for low bandwidth, low frequency communication. I am not so sure of it's suitability for much else.
OK, after checking, I wait for the server to respond before closing the connection with client.stop() so the delay is variable. I don't think it was over 2 seconds though.
The server will never respond in under 2 seconds.
BTW I have updated my notes. Just about finished although I mighty prettify them at a later stage.
http://mssystems.emscom.net/helpdesk/knowledgebase.php?article=51
MattS-UK:
Thanks for trying and I must apologies for providing you all with duff information. In my haste, I got the capitalisation wrongThe call should have been
Serial.println(WiFi.firmwareVersion());And I would still appreciate someone who has upgraded, trying it out.
The .firmwareVersion() method is documented here. See line #34
https://github.com/arduino/Arduino/blob/master/libraries/WiFi/WiFi.h
Newer here I tried to run your code but it presents a failure when I upload.
It says #include SPI.h it is not there.
Newer here I tried to run your code but it presents a failure when I upload.
It says #include SPI.h it is not there.
What code are you trying?