Recently the cloud IDE was not able to flash to one of my cores - the messages was something like “taking too long get a response”. I figured I programmed something wrong - I had seen that before when I caused the core to go into a very long loop but was always able to eventually flash. This time it simply would not flash so, figuring I did something wrong in my code I decided to do a factory reset.
Now my core is flashing blue but I cannot get it to connect when I try to set the wifi creds with the android app. I even went into the IDE and Removed the core from there hoping that would help. Nothing I do works now. The app on the phone eventually times out (giving me the continue / try again message) and the core simply flashes blue. I have a galaxy s4 that I originally used to init my cores and spotted a thread here that mentioned issues with it so I just tried an htc M8 but still had the same issue. There is a thread about a dfu for windows but the link is not working (http://dfu-util.gnumonks.org/). Any help would be appreciated. Thanks.
ok, i seem to be a little deeper down the rabbit hole. I managed to use putty to input the wifi creds (I have two cores and can see both mac addrs listed in my router's status page so I know the "bad" core has connected to it). I also extracted the id and put that back into the cloud (through the build IDE). Now when I power up the core up it flashes green (connects to the router) then if flashes blue real fast, then a series of red flashes (I can't quite count them because some are fast and some are slow - if I had to guess is does an SOS then a single red flash [then repeats the SOS + single red flash]) and then there is a single white (grand finale) flash at which point it repeats this whole sequence starting with green.
I'm guessing I need redo the keys now but (a) I'm not 100% sure if I should be going in that direction (I'm not getting any orange lights) and (b) if I should go that way then dfu link is broken in the posts i've read:
Would you mind posting your code? (whichever code is currently on there). The SOS then 1 red means a hard fault and is usually the result of a mistake in the code
There was no code involved. At least there should not have been; all the problems occurred after a factory reset (but i did remove the ID from and add it back in the IDE during this process so that may have played a role). Just now I did another factory reset, tried the android app and when that failed I did another factory reset, then connected over the USB, input my wifi creds and it started working. It appears to have gone though (another) deep update,too.
I feel like you shouldn’t have to do a factory reset multiple times tho… I guess it might be required if the first is interrupt but if not why would it ever require multiple tries?
More like: if Factory Reset doesn’t work the first time, try try try try try try try try try try try try again
Because, many many factory resets were done while troubleshooting for my first two posts.
(Harrison, I never interrupted a reset.)
Also, why doesn’t the android app work? Plus, when setting up via USB I noticed that at times i was asked to specify the wireless encryption type sometimes not. There seemed to be a range of things that frequently changed where I would have expected it to be deterministic. This could have implications for the router but since a day past between my second and third post I also have to wonder what was going on in the cloud. Lastly, does a factory reset wipe the deep update? Because I know I did that once already prior to my trouble starting but, as mentioned in my third post, I can saw it happen again after reconnecting.
That’s exactly why… perhaps that one time you used it and you thought it should have worked and it didn’t because it was interrupted and reverted to the same firmware that was on the Core before. Also sometimes you “think” you did it right, or it completed successfully… but since this was your first time… perhaps you didn’t understand what you should be looking for. Factory Reset is one of those things that should work the first try, agreed… but also should be impervious to repeating and being interrupted… so it doesn’t hurt to try again. My point’s not that Factory Reset needs to be run multiple times, but that it pays to just try something again if it didn’t work the first time for whatever reason
If you have an old "white" Core, it would be prudent to update the factory reset firmware that lives inside the Core as well. Then every time you do a Factory Reset locally, you will already have the latest firmware and the Core will not connect to the Cloud... realize it is running older factory firmware, and get an OTA update of the latest factory firmware automatically. You can update the factory firmware locally with the Spark CLI tool with the following command: spark flash --factory tinker
