did a factory reset, now stuck at flashing green : ( . this was happily connected earlier.
Just so everyone knows, this has actually been resolved now. Your next magenta update should succeed normally. Definitely keep the conversation going if not.
took a few tries, but now looks good here
Did a factory reset on the core that was doing the flashing light show, and it is back up and running now. However, earlier this morning when I flashed it⌠compile-server2 was at the same state that it is now: https://github.com/spark/core-firmware/tree/306d8bea673f49901467d02960cf294116157423
So is compile-server2 really the last stage before it hits the web IDE / factory-reset? Or is there some difference between what gets compiled with the web IDE and factory reset core-firmware?
While Iâm at it, Iâve been wanting to ask just what exactly happens during a factory reset and where does the firmware come from? Because it seems like to me itâs downloading the firmware (magenta flashing), but I thought it was supposed to be in the on-board flash memory.
Good question!
compile-server2 (soon to be renamed to something friendly like cloud-production), is the branch of the firmware repos that is used by the build servers. When you write code in the web IDE, your application is merged and compiled with this branch using a slightly changed makefile.
During manufacturing a known working copy of firmware is copied to an address on the external flash chip on the core at 0x00020000 (dfu -a 1 -s 0x00020000). When you do a factory reset, the bootloader is watching the button presses during startup, and will then copy the firmware from this special address (magenta flashing) into the firmware user-space 0x08005000, and then run that. I think it also does some diagnostic steps like wiping saved wifi profiles.
If youâre building firmware at home you can totally replace this factory reset version with a firmware that is stable and one that you trust. Then when doing a factory reset your core will revert to that version.
The over the air update process is slightly different. In this case, I believe, the core keeps a copy of the firmware you were running when you did the update, so that it can backtrack if there are problems launching the newly downloaded firmware.
Thanks!
David
Thanks for the explanation Dave.
Was just having some issues for the last hour not being able to flash from the web IDE. It would save and compile, but constantly time out with flashing. As I started typing this my core dropped off the cloud several times and reconnected in a short period of time, maybe 20 seconds max. Now I was just able to flash a simple blinky program.
What gives? Was the server just experiencing an issue or something else?
1/24/2014 11:59am CST
Iâm good to go! Last night I was in the flashing/solid magenta loop so I gave up. Plugged it in this morning and it went to pulsing cyan right away. I uploaded Blink from the IDE and itâs blinking as we speak!
The cloud is A-OK right now. The only thing that might have been residually effecting you is if the local Wi-Fi network was janky enough to prevent a long OTA update. Last night I also reverted a commit that was intended to make OTA updates more reliable, but it also made them much slower. The slowness may have exacerbated Wi-Fi instability.
I wasnât getting any magenta indication at all from my core when the OTA was failing⌠which led me to believe nothing was getting to it⌠but it was happily breathing cyan for over and hour while that all occurred. Also restarted it a few times, and rebooted my wifi several times (which is a tethered iphone wifi hotspot). It connected back to the cloud fast, and the internet connection through the hotspot was fast. When things like that happen, I wish there was a good way to debug it⌠maybe using Wireshark would help? If anyone has any good tips along those lines, Iâd love to help debug these things.
Just to update that nothing has changed with my original situation. After a short period ~ 10 secs of flashing magenta I either get solid magenta or no lit led at all.
Last night I thought Iâd try again - I must have tried about 60 times before I did manage to get through an update and got to breathing cyan. So I believe it now currently has latest firmware. However any subsequent Flash update from the cloud only manages the same 10 secs of flashing magenta before dying so nothingâs improved.
Iâll await sprint 6 but it sure is frustrating to not be able to use my Spark yet from the cloud. TCP is reslient in pacing and error correction so I just donât understand why thereâs such an issueâŚ
Hello @xAPPO I can understand your frustration. The CC3000 WiFi module sometimes has problems with keeping a TCP socket open on certain networks, which makes the OTA flash updates inconsistent. Have you had a chance to try it out on a different network?
I have tried it on 4 different WiFi Access points but all on this same network. They all behave the same. I will try and test it on a completely different network although that isnât a workable solution for me of course.
Is this something that is going to get a firmware fix or are you saying the hardware is problematic and you canât remedy it ?
What aspect of the network causes the problem ?
K
What aspect of the network causes the problem ?
Dropped packets. Often caused when there are a lot of other networks, or other RF noise.
Is this something that is going to get a firmware fix or are you saying the hardware is problematic and you canât remedy it?
This should be fixable via a firmware fix. There have been multiple incremental improvements, but clearly still room for improvement.
@xAPPO have you tried compiling locally using the core-firmware repo and flashing using dfu-util? That is another option. Also, weâll be releasing a command line interface that will make local compiling + flashing easier as well in the next week or two.
I have had the same issue. I was able to get the spark core up and running perfectly on my home (non busy) network. I then brought it in to work where the Wifi network is has much more traffic and keep running into the issue where it would establish a connection for like 30 seconds and then drop off the network and reconnect and drop off etc etc. I thought it might have been an issue swapping Wifi networks so I reflashed to factory firmware and now am at work stuck in this solid magenta - missed packet state bc it is trying to download latest firmware. I will bring it home and reconnect it to a less traffic network to get back up to speed but would like to see improvement in the packet dropping recovery as I was planning on using this for an application at work.
Other than this issue I have loved using my spark core. I have created a Node.js web app that controls it using the apiâŚawesome stuffâŚwhen I can talk to the deviceâŚ
Progress has been made, and thereâs still room for more. In particular:
- weâre rolling out the last 3 weeks worth of firmware updates tonight
- the CFOD buffer overrun patch from TI coming later this sprint should help as well
Also, note that anytime you do a factory reset, youâre back to square one here unless you update your factory reset firmware. If you follow the âflashing yellowâ troubleshooting instructions to overwrite your factory reset firmware with a more recent image, youâll have a little better luck because your Core wonât have to get the auto-update when it first connects.
Awesome. Looking forward to it. Thanks for the quick reply.
Other than busy network / dropped packets, would there be any other reasons why it would be in a connected -> disconnected -> connected -> disconnected etc etc etc loop like this?
Also signal strength is not an issue as I tried in multiple location relatively close to our wifi routers.
not super concerned with having to reflash it as i can do that easily enough on my home network.
Noisy RF / busy network is definitely the primary cause of that behavior. You might see something similar if your code is broken in certain waysâgood enough to build but causing a hard fault at runtime on the device. Thatâs pretty rare though.
Ok cool that is what I figured. Working in a large web dev shop with many people all using macs + wifi and multiple wifi access points so this is probably as noisy as a network as this device will see!
It might be coincidence. But I was powering the core off a cable plugged into the back of my Mac cinema display and having problems retaining a stable connection. I switched to a 1000mA supply and it all works a lot better.