v0.11.0 Causes hangs on MKR1000

[youcangetme]

Just updated and it took me a while to narrow down which lib was causing the freezing.

I'm a very high level developer so I apologize for not being specific but I can revert to v0.10.0 and it will work again.

Specifically, if I hard code the network SSID and password it runs flawlessly. If I use the FlashStorage lib to load the data it will freeze. Oddly enough the Arduino IDE Serial Monitor will hang (as in I click to close and it will not do so) too until I power off the MKR1000. The only way to power on and flash the memory again is to disconnect power to all external components before booting. If even one I2C or SIP module is connected I can't get the MKR1000 to flash.

I discovered which lib it was by backing out each library until it worked again. I can have all libs up to date and just the WiFi101 at v0.10.0 and it will all work. Update to v0.11.0 and it fails.

It does seem to connect to the network and obtain a IP address. It seems to fail around the use of the multicast socket client to listen for a broadcast packet. Sometimes it receives the packet and hangs and other times it hangs before the pack is received.

Sorry I can't be more specific.

[sandeepmistry]

Hi @youcangetme,

Before anything can be done to resolve this issue, more details are needed.

Could you please provide a minimal sketch to reproduce the issue you described, along with a detailed sequence of steps to follow.

[youcangetme]

I will try to get a stripped down version of the app into a sketch for you. Give me a bit as the app is complex being that is has several modes of operation.

[youcangetme]

I simply don't have the time to simplify the app. I instead shared it with you as read only via an invite; https://github.com/subnoize/dstlr-mkr1000/invitations

It starts up in AP mode and you navigate to a page and enter your SSID, password and the email address is recorded but not used. Once that is set, reboot and the MKR1000 should join the network. If you navigate to the unit via HTTP it should send some data about IP, MAC addrs. If you can't get it to show that data then its having trouble. If you need the server that is generating the beacon I can give you access to that code as well. Eventually this will be an open source project but I would rather not put in the public view until I have it a bit more polished.

You can comment out the Adafruit I2C sensors. It doesn't require them to operate.

[sandeepmistry]

No rush on simplifying the app, let us know when it's done and can be shared publicly ...

It seems to fail around the use of the multicast socket client to listen for a broadcast packet. Sometimes it receives the packet and hangs and other times it hangs before the pack is received.

How large is the packet? Over 1400 bytes? Can you please try the patch in #116 if that's the case ...

[youcangetme]

I try to keep UDP packets sub 64 bytes. The buffer is exactly 64 bytes on the server side. Basically the time in seconds from epoch and the 4 digit port number the master is listening on. Nothing special beyond that. The beacon is broadcast about every 30 seconds. Its makes the IoT devices self configuring once you give them the SSID and password and they join that access point.

[bcraigie]

+1 from me. I am using data from an FRAM rather than Flash, and it simply loads the data into a Struct which has the SSID defined like this:

struct config_t
{
  char SSID1[17];
  char SSIDPW1[33];
  char SSID2[17];   
  char SSIDPW2[33]; 
  char SSID3[17];   
  char SSIDPW3[33]; 
  unsigned int myChannelNumber;
  char myWriteAPIKey[17];
  char myIP[16];
  unsigned int myPort;
  unsigned int myFrequency;
   
} config;

and the connect statement is just like:

myStatus = WiFi.begin(config.SSID1, config.SSIDPW1);

I've defined char[17] for the ssid so that it allows 16 characters plus the null for the ssid.

So I don't know if it is just a red herring that hardcoding the SSID fixes it? Presumably the Wifi100 library can handle the SSID from a char[17] and password from char[33] without a problem?

Library version 0.11.1 was giving me immense grief with hanging a few seconds after the begin statement or on the first data transmission thereafter.

Reverting back to 0.10.0 sorted it all again.

If I can be of any help, just let me know. I dumped out the values from config.SSID1 and found that there were remnant characters from a previously stored SSID after the null terminator of the current SSID

For example if the SSID is "myssid" and previously it had been storing : "mylongssid"

The dump of config.SSID1[17] shows:
m y s s i d [null] s s i d [null][null][null][null][null][null]

Would this cause the WiFi.begin a problem? I can't see in the documentation a maximum size for the ssid or password to be passed to WiFi.Begin although I might simply have missed it.

[sandeepmistry]

Hi @youcangetme,

Please open a new issue with more details like a minimal sketch to reproduce the issue. Your issue seems to be unrelated to the original issue reported here.

[youcangetme]

@bcraigie if you could come up with a "proof of operation" sketch for @sandeepmistry I will owe you! I've been buried and haven't had a chance to get an example running. You are experiencing the exact issue I am even though its from different libraries. No need to create a separate ticket.

[bcraigie]

I will endeavour to do so. Since you have the problem with 0.11.0 it is likely that I would also see the problem with 0.11.0 - I didn't try that version, and just reverted from 0.11.1 to 0.10.0 so as you say, we probably do indeed have the very same problem.

What I can say is that I developed my code with a hard-coded SSID and Password initially and it all worked great. Only when I introduced saving the SSID and password to the F-RAM and loading that to pass to the WiFi.Begin did I start seeing the hanging, and even then only after having changed the stored SSID from a longer SSID to a shorter SSID. So at present, I'm working on the assumption that the WiFi101 0.11.x library has a problem with the way the ssid and/or password is passed to it, and probably the extraneous characters after the null.

Because the problem only shows up when we read from Flash or F-Ram, a minimal sketch might not be so minimal :-)

[sandeepmistry]

Because the problem only shows up when we read from Flash or F-Ram, a minimal sketch might not be so minimal :-)

Maybe we can start with a non-minimal sketch? It's better than having no sketch to look at ...

[sandeepmistry]

@youcangetme @bcraigie there's a new v0.11.2 release with a fix for WiFi.RSSI() crashing. Could you please test again with this version?

[bcraigie]

My Sketch runs perfectly on 0.10.0 but I'm sorry to say that on 0.11.2 (and 0.11.1 and 0.11.0) it hangs the Arduino.

[bcraigie]

This page would not let me upload zip files or .ino sketches, so I've put my .ino file at this Dropbox link. This is my full project file because I'm not sure if I can strip it all down to a minimal sketch and still get it to hang (maybe there's some interplay between libraries).

It also requires an extended F-RAM library which I've updated (so that it will read and write the whole struct in one go).

I am also using Thingspeak library 1.2.1 and DHT Sensor Library 1.3.0

Also, here is the Fritzing breadboard layout.

Hope that's ok.