Spark core won't allow a reflash after I load this code

Hi @jaysettle

Spark.publish() is rate-limited to an average of 1 per second with a burst of upto 4 allowed as long as the average is maintained. I think you are running into that limit since you main loop only delays for around 1/2 a second.

There are some problems where you code makes web flashing impossible without a factory reset, so I sometimes add this little piece of code at the top of my loop().

   // declare D0 as an input above.
    int pin = digitalRead(D0);
    if (HIGH==pin) {
        Serial1.print(" Waiting...");
        for(;;) {
        SPARK_WLAN_Loop();
        }
    }

This allows me to test my code with pin D0 tied low, but if I have trouble, I can tie D0 high and hit reset. Then the core will infinite loop running SPARK_WLAN_Loop() which processes all the Spark requests and allow you to flash new code. You can change it to use any pin.

2 Likes

Publish is inside a loop that runs after 7 seconds is up. Thanks for the suggestion! It’s still really flaky though.

1 Like

Using the pin-check loop is a good suggestion. Does that D0 circuit include any resistors?

In my project I added a 20 second loop in the setup() function to allow for flashiing after reset. After that my Core gets disconnected from the cloud to improve stability…

I just move the wire on the bread board when I am debugging but you could add a pull-down resistor either externally or by changing the pinMode() call.

@jaysettle: perhaps the OTA flash is restricted by the size of your code plus libraries used.

In the past two days I had problems with OTA flashing too. As I found out, in my case there appears to be a code-size related restriction. As soon as the code-size is about 97.7% or more, flashing doesn’t work. The IDE message is that flashing went okay, but the purple led-flashing doesn’t start. When encountering this limit, removing any piece of code helps. I reproduced this issue by adding and deleting debug-statements.

My Spark Core project uses a couple of handy libraries that increased the program size. My own code is less than a couple of KB. Now I’ve cleaned up my code a bit to allow for further development, but it’s a pity I can’t use the full 100%. Even calling a function like analogWrite will increase the size with a couple of percents, so I guess this call’s for more effective coding or maybe even stripping out unused code from the libraries…

@maxint, the linker will take care of omitting any library code not used by your program. Which “handy” libraries are you using?

Hi @peekay123. Thanks for your reply. I indeed experienced that library code is only included when used. When adding the call to analogWrite (for smooth led-lighting) the size went up more than that of just a single function call, so I guess that for analog out another library-part got added to the mix.

The handy libraries I use in my project are Webserver (which has plenty of code candidate for stripping out), Adafruit_mfGFX_IDE (without the extra fonts enabled yet) and the Spark port of Adafruit_PCD8544 (by pkourany :wink: , which is not published as a library yet). On top of that I added some custom code (excluding all comments probably perhaps 250 lines).

@maxint, a classic killer space eater is sprintf which adds about 20KB of flash! Yes, adding some function calls will pull in all the dependent functions as well. To reduce the final size of your code you will need to optimize the code that is actually used and sometimes, that is not always easy if it’s in a library.

Nonetheless, the “maximum” size of code that can be flashed via OTA is of concern. Can you flash the same (97.7%) code via USB?

1 Like

@peekay123, thank you for your tips. (But thank you much more for the PCD8544 Nokia5110 port!)
BTW. Forgot to mention that I also use the SD-Card library.

I do use functions such as sprintf and vsprintf, but wouldn’t want to code without them.

I guess when required I need to make my own version of the Webserver library. That library contains some code I don’t use and some I even don’t want. (I.e. my webserver serves files from the uSD card, so that library-default icon is just wasting space!)

I haven’t installed the dfu-util yet. So far I managed to get where I want using the online IDE. There the experienced limit seems like a strange anomaly and I wouldn’t expect that from flashing using USB. It’s worth a try though…

@maxint, personally I use the Spark CLI almost exclusively for all my coding. It gives me the most flexibility. I also have a local toolchain for testing unreleased versions of the core firmware. :smile:

@peekay123: I just read here that on Windows the flashing utility is’n really straight-forward. On mbed I can just copy and paste the compiled firmware.bin. Do you know of something similar for Spark Core?

Edit: BTW. those libraries mentioned are in addition to those that I didn’t need to add, such as for the Servo class, which is likely to take space too. What bothered me most was that - as it seems - OTA flashing can break before reaching 100%. It took some hours before I realized that one was related to the other…

I’m still having reflashing problems. I’m using the spark web app. I’m not uploading through usb at all. Could this be a problem with space requirements with just the little code I have pasted above. I hope not.

I’ve since claimed the spark core unreliable for over the air uploads. Please restore my faith.

@jaysettle: what percentage do you see after using the Verify?
(To see click the (i)-icon behind “Ready” or “Code verified! Great work.”)

Does the IDE say that flashing was succesfull or not?

There is some interaction that I don’t understand between publishing and being able to flash OTA.

As a test @jaysettle can you comment out your actual Spark.publish() and see if you can reflash then?

I know this is not a perfect test but it will point in a general direction.

@maxint, I am not having ANY problems using DFU-UTIL on Win 8.1 x64 and never have. I have dfu-util v0.7 and soon 0.8 once someone compiles it for windows and makes it available. I created a one-line batch file (flash.bat) to flash to the connected core:

dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D %1

So I simply use "flash firmware.bin" when I compile locally to flash my code on the core. :smile:

There is a make target for flashing in the makefile so you can build and flash in one command line:

make program-dfu

There also a cloud flash target that uses curl:

make program-cloud

I’m at work now but I can remember the IDE says unsuccessful. I get no indication from the core from watching the LEDs that it has received code over the air.

I will try to comment out “publish” when I return home.

Never heard of DFU-UTIL. Is this used in confuction with spark web app?

Thanks.

@peekay123,

@mdma did compile it a while ago "for testing" :slight_smile: works a treat for me

1 Like

Its a tiny program that lets you flash the core via USB. you can use it with the Spark CLI or by itself. It takes about 20seconds to transfer the code onto the core!

With the CLI its really simple, i use the cloud button next to the name in the Build web IDE to save firmware.bin into a folder, then run spark flash --usb firmware.bin from a cmd prompt

how to here : HOWTO: Update CC3000 via DFU-util (windows) - Troubleshooting - Particle

1 Like

Was there a resolution to this issue? I am having the same problem, it appears to be the graph.plot() function that is hanging.