I am faced with an unusual problem and was wondering if someone can shed some light.
After flashing my firmware to the core, the core seems to be stuck at that very rapid flashing cyan light phase that is just before the connection and the micro controller starts (that is, before the breathing cyan light).
I have attempted to reset the core, factory reset the core, unplugged and replugged the power, and come back to the same problem.
Re-flashing a smaller firmware solved the problem. What possibly in my code could cause this?
Hi @timolol - the very rapid flashing cyan is the handshake with the Cloud; for some reason, your Core is not completing the handshake successfully. Some users have reported that the Core never gets through the handshake, and that’s probably because the RSA keys on the external flash were corrupted. However if you see this behavior intermittently, it must be some interaction with your code. Could you share your code, or explain what it is you’re working on, so that we can help debug the issue?
The code you build and flash to the core is run alongside the Spark firmware that takes care of connecting to the cloud, doing encryption, etc, etc. It’s possible your program allocates enough memory globally that is causing the core to run out of ram before it can finish the handshake.
I believe we have to define some numbers on this side to be able to constrain end user usage: is it possible to calculate the firmware memory requirements and subtract those from the total memory to publish the user available memory, flash storage and so forth?
Thanks for the reply guys! I think you are quite right about too much global variables allocated to memory causing the problem with handshake. A revision of the code does allow core to complete the shake, however after running the setup() just before it enters loop(), the core disconnects itself and then reconnects itself. However after the reconnection, Serial output and all the Spark functions and variables render unavailable.
Is the self reset also an indication of not enough memory?
Sorry to bring this topic up again, but I have spent a few weeks (during my spare time) to circumvent this problem with no success.
What I am trying to do is to have this particular core to control the lighting and power switches. And in order for the web interface to know what are on, off, brightness level, colour level, etc., my thoughts were:
have individual variables keeping track of the status of individual devices
have a status update function that converts all the variables to a JSON String by using sprint()
expose the status String as a Spark.variable
call the status update function in the loop()
have a timer on the client side (web interface) that fetches the JSON String from the core and update the interface
The problem with this is I inflate the program with many global variables which causes it to crash. What would you recommend me to circumvent this problem? What would also be the best practice to pass on all the variables in one go to the client side?
This appears to be the closest topic to what I’m having difficulties with, even if it is 481 days old. I have been making slow but sure progress on a project, only to hit a brick wall yesterday when my Core started doing almost exactly what is described in the opening post. Basically, the Core hangs at blinking cyan (before starting the application), but does a random fast/slow flash sequence forever. I thought it was the large code addition that I’d made to my project (bringing the BIN size to about 87KB), but I pretty much stripped the program down to nothing trying to unsuccessfully isolate the problem. (Yes, I did make a code backup first!) Obviously, when it won’t initialize, the only options are DFU-UTIL or a factory reset (for OTA programming).
At first, I could factory reset and FLASH Blink_LED onto the Core (via OTA or DFU-UTIL)
and have it initialize to breathing cyan (and blinking D7)–but now that doesn’t work anymore.
I can still factory reset to Tinker, which initializes to breathing cyan. It’s fully initialized, as I can control it from my phone–or pretty much soft-brick the Core by flashing Blink-LED or my practically empty program to it. --WAIT–now that isn’t working anymore! An OTA flash goes to flashing purple on the Core–but it gets stuck with “purple” for a few seconds, “off” for five seconds, maybe five purple flashes, then back to stuck. Then it just gives up, resets, and blissfully initializes to Tinker (breathing cyan).
I can DFU-UTIL the Blink_LED BIN file onto the Core…but after the green-flash “Connecting to Wifi”, I just get the “broken lawnmower” rapid random alternating between fast/slow flashing cyan, and it won’t start. What on planet earth have I done? (I know I haven’t done anything on Mars ).
I’ve successfully done DFU-UTIL flashing before, so don’t think that’s the problem. Perhaps @kennethlimcp has some insight?
I can communicate with the Core via Tinker (after a factory reset and WiFi setup), so it doesn’t appear to be the Cloud keys.
I’ve seen more error codes from this problem than with any prior one! Three red flashes, or one long red flash–or 3 seconds of rapid red flashes, or any other combination of resets, etc. My Wifi is good, running ~5MBits up, ~2MBits down to the Internet.
Just for the record, I created a shortcut in “C:\Users\[username]\AppData\Roaming\Microsoft\Windows\SendTo” linked to DFU-UTIL, so I can right-click a BIN, and click, “FLASH with DFU-Util.” The shortcut’s target is [“dfu-util.exe” -d 1d50:607f -a 0 -s 0x08005000:leave -D]. Windows automatically appends the %1 on the end.
Sorry if that's a forum rule, but I was trying to be as descriptive as possible, so I wouldn't waste someone's time suggesting something I'd already tried.
OK, I tried a CC3000 flash...DFU-UTIL'd Blink-LED, and bam--it worked perfectly. (Also worked perfectly with my stripped-down code.) I've flashed the CC3000 before, so my question: How in the world did the CC3000 get corrupted?
Yes, if it was code, I was going to share it! But when Blink_LED didn’t work, I knew that there was a deeper problem. Thanks a lot for the solution. I’ll try it the first thing if experiencing difficulties again…
Wow, thanks! I had the issue a couple more times (fixable with another CC3000 patch each time), and was wondering if I’d ever be able to complete my project! I’m assuming this was a realtime patch applied to every future “Compile in Cloud”, so I shouldn’t have to wait for version 0.4.0.?
Quick question: does the CC3000 reflash overwrite the deep-update for the CC3000? Or are they separate?
The staging version of firmware was meant for us to test changes on another set of servers, so the rapid cyan flashing you saw was your device trying to connect to a staging server, but having a keys mismatch. Hopefully things should be back to normal now. The deep update / cc3000 patch are essentially the same, and deep-updates for the photon should be delivered more smoothly than with the core.
core to control the lighting and power switches. And in order for the web interface to know what are on, off, brightness level, colour level, etc., my thoughts were:
).