Hey all, I just flashed the deep-update after not using my core for a while.
Now that it’s done, I tried doing a factory reset, and whenever I hold the mode button for 3-seconds to get it to go to listening mode, the LED indicator light freezes on whatever intensity it was on (while slow-breathing cyan). I can put it into DFU mode, and reflash firmware, but no matter what firmware I flash (my own, or the default tinker) it has the same issue. Given this, I would presume it has something to do with the CC3000 patch included in the deep-update, since the tinker/personal firmware doesn’t seem to make a difference, however it would seem strange that the CC3000 firmware would have such an impact.
Any ideas?
Where did you get deep update from?
From the spark-cli toolset.
I ran the default install:
$ npm install -g spark-cli
and then
$ spark flash --usb deep_update_2014_06
EDIT:
I also compiled the 0.7 version of dfu-utils, to make sure I had the latest version, so it shouldn’t be an issue on that end.
Can you run it again?
Tinker should run after the update is completed. I did a test yesterday and it was ok 
Yeah, it seems like others aren’t having issues with this, so I’m presuming it’s some weird isolated issue.
Just ran another flash:
sudo spark flash --usb deep_update_2014_06
FOUND DFU DEVICE 1d50:607f
checking file /usr/lib/node_modules/spark-cli/binariesdeep_update_2014_06.bin
spawning dfu-util -d 1d50:607f -a 0 -i 0 -s 0x08005000:leave -D /usr/lib/node_modules/spark-cli/binaries/deep_update_2014_06.bin
dfu-util 0.7
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 93636
Download [=========================] 100% 94208 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Flashed!
EDIT: The same issue persists.
So the issue it seems is that you are unable to enter listening mode?
That is correct.
Any attempt to do so freezes the device.
Just hold on MODE without hitting the reset button for 4 seconds
I have also tried running the
$ spark flash --usb cc3000
Which completes successfully, in the same manner as the quoAfter which, it stays flashing magenta until the device is reset
(rate of ~2.5x/s).
Upon putting it in DFU mode, I can then flash
$ spark flash --usb tinker
which again succeeds as above, and it transitions to a breathing cyan state.
When I hold down the MODE without hitting reset for 4 seconds, the device freezes. That is the issue that I’m having.
Interesting! So it can do everything but not enter listening mode?
Even a factory reset does not put it in listening mode?
Are you able to flash via WEB IDE? I can give you a code which forces it to enter Listening Mode and see the result.
That is correct, attempts to put it into listening mode causes it to freeze.
Otherwise, I believe it’s working okay.
A factory reset does not put it into listening mode, it goes straight to breathing cyan, which it shouldn’t, obviously.
Regrettably, I don’t have access to the device id, as I had unlinked the core from a shared account that myself and my development team were using, and when I went to relink it, it said it was unable to relink the core. That’s when I attempted to reflash the core, and ran into issues. I’ve since lost track of the device id, and have no way of flashing over the web IDE.
Is there a way to force it into listening mode from the command line, or via a .bin file that could be flashed?
Yes. Maybe I will give you a .bin file to flash via DFU and see if it Is possible to force into Listening Mode.
Will be back once I compile it
I appreciate it, thanks for your help.
Thanks!
Unfortunately, I don’t think it worked.
Once it finished flashing, it went back to breathing cyan.
It flashed just fine, but if I try to run:
$ sudo spark identify
I get:
Something went wrong Serial timed out
So it’s like it can’t properly transition to the listening state.
Also, holding the MODE button freezes the device still, like before.
I.E.: the problem still exists.
It sounds like a corrupted user firmware since the Listening mode is not controlled by bootloader…
Can you reflash tinker? Sorry for so many instructions 
For those of us new and uninformed, what exactly IS a “deep update”?
@damccull, it is supposed to be a patch for the CC3000 Wifi module to improve stability.
If you are new, ignore this. An official announcement will be made by 
HQ with regards of how to perform deep_update with proper documentation 
I have indeed reflashed tinker, with no change in function. The problem persists.
I am not sure of how to delete the existing WiFi profiles, as typically it would be done by holding the MODE button for ~10 seconds, at which point it would rapidly flash blue, signifying that they were cleared. As soon as it gets to ~3 seconds of holding, the device freezes.
EDIT: If I perform a factory reset, the devices goes through the two segments of rapid flashing white, then it does the 3x/s blink of white, as it should for a first initialization, but it never leaves that to go to the listening mode. It goes back to the same blink rate if I reset the device.