When tinkering with your own code bricks a spark core

Hi SparkIO Community,
This is my first post. I’m a software engineer with a masters in computer science.

This is SUCH an awesome product.
After 12 hours of experience I have a few product ideas.

The initializing of the wifi settings from IOS is a little buggy. Maybe it’s my network? I am using an Apple Airport Extreme with WPA2, but I only got it to work once. Other IOT devices publish their own SSID’s and let you connect to that SSID from your phone or tablet initially to setup the wifi settings. I ended up resorting to the Serial update because it just took ages / only worked once.

I wish there was a way to reload the Tinker Firmware without going through the wifi settings. (though I’m sure that I will also be glad that there is a way of updating the wifi settings without reloading the Tinker Firmware app) The two are mutually exclusive.

Currently when we crash our custom code, say by dividing by 0 or traipsing off the end of an array (lets not pretend here, we’re all professionals), it reloads the custom firmware and restarts automatically. THAT is cool, but I’m not sure that’s 100% what I want. I could see that being useful when I’m DONE with an application… if for some reason my “finished” application crashed, I would want it to automatically start over. What would be better during development is for it to reload the tinker firmware if it crashes. What might even be better yet is to reload the last saved and verified firmware from the cloud. Look at it from a developers stand point: I want to be able to do development remotely.

We could have a bool for load Tinker Firmware on next Restart. That alone would be a catch all for development.
If the spark has a valid wifi connection it should never need to be reset to factory default.
It could log into the cloud service and pull down a bool for what to do next, then do a default action if that times out.

We should have a Create Access Token in the cloud service settings tab.
Also, under the Cores tab, there should be a few auto generated URLS such as, List Currently Declared Functions, and List Currently Declared Variables. If there are functions we could generate buttons to call them. If there are Variables we could click on them for their current value.
The idea of the Access Token was not immediately obvious, nor were the URLS for accessing variables.
It seems like an easy couple things to do in the cloud service.

Just some thoughts from a 12 hour NOOB.
This is SUCH a cool product.


Hey @seanreynoldscs!

Thanks for your input, some really good points there!

The SmartConfig used by the TI chip to communicate over WiFi without actually being authenticated on the network has some known issues, and the soft AP process is not available on that chip. Photon will use a soft AP process, and our mobile app will talk to this to setup the Photon, which will be reliable and use standard infrastructure, rather than clever hacks! :slight_smile:

You can restore the tinker firmware without resetting WiFi credentials by using the spark cli. First put the core in dfu mode, then run:

spark flash --usb tinker

It’s been mentioned before that we should have a way to start the core in a “safe mode” where it doesn’t run the user firmware, but still brings the core online, so that new firmware can be flashed. This is possible - the hard part is deciding on what combination of buttons or how else we trigger safe mode!

Spark Dev - our local ide provides direct access to functions and variables so might want to try that. In time, the same features will migrate to the web ide also! Although adding URLs to the spark API for variables and functions seems like a quick win!

Thanks for the input!

1 Like

Hi @seanreynoldscs
Are you saying that you DID get the Core to work on your Airport Extreme with WPA2, but only via USB tether and command line setup? Do you have the 802.11ac version?

I just posted an issue where I can’t get my Core to connect to my Airport Extreme (ac version) even from the USB tether. So if I at least know it’s possible with that router, it would help me diagnose. Thanks.

Yes, I did get it to work with my airport extreme ac version.
Connected it to the computer via usb.
Put the device into WIFI setup mode (slow blinking blue light)
Opened the USB serial connection, via CoolTerm
Pressed 'w’
Carefully typed my SSID “Strathearn Manor” with capitals and space just like that.
Pressed Enter
It gave security options, I believe default is WPA2 which is option 3
Then carefully typed my password
Pressed Enter,

It worked for me very quickly.

Thanks. Unfortunately those exact same steps did not work for me yet, but this gives me hope that I will get it working with that router eventually.

Awe, that makes sense that the AP process could be limited in some chips. I understand completely. I still this the spark core is SUCH A COOL PRODUCT!

Thanks for the heads up! I’ll have to give DFU and Spark CLI a try!

It is super complicated because a program could enter a infinite loop and never actually crash…
Is there any way to phone home on startup? Usually if I crash my core, I know I did it.
If you could phone home then a boolean for that core in the web ide could be the easiest?

Spark Dev?? I’m so new I didn’t even know there was a Spark Dev!! I’ll definitely check that out too.

I’m going to jump this over to your thread.

Infinite loops are handled by the Watchdog timer. If the watchdog isn’t notified periodically, the device resets. (Some say “kick the watchdog”…but that sounds like kicking a dog which I don’t like!)

One way to fix broken firmware is beeing able to flash code while the core is offline, and then it fetches when it reboots before it starts running the broken code (or course with a wifi timeout)

I imagine you could phone home on startup by calling Spark.publish() in the setup method.