Spark Cloud SRAM usage

I have not been using the cloud with most of my projects, however I started to enable the cloud and have noticed an interesting behavior. My core drops it’s connection much more frequently with the cloud connected than when not connected. I would like to know if there is a recommended amount of SRAM to keep available for the Spark cloud.

My application uses the following resources -
Flash = 103,460
SRAM = 15,525

That leaves 4,956 SRAM for dynamic allocation and stack.

With the cloud enabled my application looses it’s network connection 10x more often then when I don’t have the cloud enabled.

Any ideas?

My experience says that it should work fine. What are you using the cloud for? I at one point was exposing String variables, and using dynamic allocation/concat of strings that was causing memory issues. Switching to char arrays and snprintf* has solved a lot of those problems. Of course, It’s a little hard to diagnose without knowing more about what your program is up to. :slight_smile:

*as opposed to sprintf. snprintf is given the length of the char buffer, and prevents buffer overruns and kernel panics…

@mumblepins,
I was going to use the cloud for firmware updates. I mounted the core under the LCD display and as a result I was not able to get to the buttons to put it into DFU mode, so I was hoping to enable the cloud so it would take firmware updates OTA. I also bring up the cloud at boot only long enough to get the time. So in my two identical cases, 1) bring up the cloud to get time and call Spark.disconnect(). 2) bring up the cloud and leave it connected.

Case 1) I get CC3000 failures where the RGB goes to blue, green, and cyan about 3 / hour.
Case 2) I get CC3000 failures where RGB goes to flashing green and then breathing green about 2/day.

This was observed from a short run yesterday ~ 1 hr on case 1.

What was strange was that even with the cloud connection up I was unable to send it an OTA using spark flash ####COREID### firmware.bin and spark list did not show it online, however in the IDE under cores it was listed as being online.

I gave up after about 1 hour of debugging.

Connecting to the Internet only requires the Core to successfully connect to your Wifi router.
Connecting to the Spark Cloud requires Internet connectivity and then successful connection to the Spark Cloud. So connecting to the Spark Cloud has more failure modes than just connecting to the Internet.

It is my understanding that the Spark implementation of Internet and Spark Cloud connectivity are linked in the Spark Core. Specifically, if Spark Cloud connectivity is lost, the Spark drops the Internet connection and then attempts to reconnect to the Internet and then to the Spark Cloud.

If your program is communicating with the Cloud regularly, then this makes it more likely that the Spark Core will detect short-term outages in Cloud connectivity, and so drop the Internet connection.

Other threads discuss other issues around connectivity in the Spark Core. Spark have committed to resolving a connectivity issue I am interested in in the Photon. So this part of the firmware code will get some attention in the Photon. Hopefully Spark will logically separate Internet connectivity from Spark Cloud connectivity.

One of my sites (in New Zealand) has a flaky internet connection, so I see a lot of disconnects.

@philipq Thanks for the reply. I understand the different phases of the Spark connecting to the WiFi router and Internet. The RGB led will show you the different phases of the process as follows -

White -             CC3000:Disabled - WiFi radio off
Blue Flashing -     CC3000:Enabled - WiFi radio on
                          we do not have credentials for connection to router
Blue Breathing -    CC3000:Enabled - WiFi radio on
                          we have credentials for the WiFi router
                          but we are NOT connected to the WiFi router
Green Flashing -    CC3000:Enabled - WiFi radio on
                          core attempting to connect with WiFi router
                          using stored SSID and Password
Green Breathing -   CC3000:Enabled - WiFi radio on
                          we have established a connection with the WiFi router
                          we have IP, Netmask, DNS, Router IP settings
Cyan Flashing -     CC3000:Enabled - WiFi radio on, connected to Router
                          Spark is attempting to connect to Spark Cloud Servers
Cyan Breathing -    CC3000:Enabled - WiFi radio on, valid IP settings
                          fully connected to Spark Servers

In my case when the Spark has Cloud enabled and connected to the cloud (indicated by Cyan Breathing), the failure I get is w/ the CC3000 chip as the RGB led changes from Breathing Cyan to Blue.

I don’t believe my issue is about internet connectivity to the Spark Cloud Servers.

I think the Photon will be a nice change as we will be using a different WiFi chipset as well as having significantly more SRAM.

This is not true and is the difference between flashing cyan (no cloud) and flashing green (no router). Sometimes things go very wrong in the WiFi chip or your code and the core "reboots" but the cloud and WiFi are not strongly linked except that cloud requires WiFi and the cloud will try to re-establish a connection in any way possible.

With the controlling your connection system modes manual, semi-automatic, and automatic, you have more control. People have trouble when they want the cloud but they would like a cloud failure to fall back to a no cloud mode, but in todays' code the cloud connection will retry blocking user code and only when that retry fails will the core force a retry of the WiFi connection.

This is done in manual mode, but if you want the cloud, today you have to live with the cloud wanting to be connected when you tell it to connect. In the future you may have more control, but today if you want to be in full control just avoid the cloud and manage failures yourself in manual mode.

I would check your router logs and see if there is something interesting in there. This is not a common failure mode in my experience.

I agree with you. That was partially my point. The Cloud requires WIFI and hence a Cloud connectivity outage forces a WIFI reset.

The approved method for detecting connectivity in Core code is "Spark.connected()". As I understand it, this returns true if there is both WIFI and Spark Cloud connectivity. I don't know of any other approved method for detecting just WIFI or just Spark Cloud connectivity. In my mind, this makes the two logically and strongly linked.

Referring to logically separate Internet connectivity from Spark Cloud connectivity:

Do you mean this is done in Spark or in Photon? I am familiar with and use manual mode (in Spark Cores) to provide more control over connectivity outages. I don't see how manual mode provides any more control over distinguishing WIFI outages from Cloud outages (in Spark Cores). Can you please clarify how to distinguish the two?

WiFi.connected() is how you can check if you have established a valid WiFi connection with the router.

Here is a very good example of all aspects of the management of a core internet connection. It breaks down the CC3000, WiFi and Cloud connections. It's a good read to learn how you can manually manage your internet on the core.

1 Like