Thanks guys ! With the update of the dfu-util version, the step that you (@kennethlimcp) told me to do worked ! strangely the Core is unable to receive the credentials from the mobile app (I will try to with usb), but that wasn’t the problem before. The Core was able to receive the credentials, but wasn’t able to connect to the wireless network (flashing green)
Let me know how it goes. I havent met a case where patching doesnt work
It finally worked, but everything is kind of hard and slow. Sometime I need to relaunch the connecting process a couple of time for the Core to finally get the credentials, the flash can take something 2 minutes and the factory reset work 1/3 of the time. Should I try to run over your instruction one more time ?
Is this happening with your own code or tinker?
The patch will resolve the flashing green issue and everything else should work fine!
What is the relationship between ‘deep update’ (eg 2014_06) and the cc3000-patch-programmer.bin? Is the latter included in the former, or post-date, or pre-date it, or an instance of it?
I think that one (or both) are run-once programs and that the equivalent of setup() and loop() are used to patch other components, and hence why they must be immediately replaced by our own user-written firmware - is that correct? Does it have to be Tinker, or will any of my own programs suffice?
My Core has gone in to flashing green mode for the second time since I’ve had it. I don’t know which of the numerous steps I used last time fixed it so will follow your steps to try to resolve it. For me, having a clear understanding of what each of the repair steps, such as factory reset and deep-update, actually do and which ones are undone by other repair steps would help.
1.) Deep update is doing what CC3000 patch is doing except that it attempts to minimize disruption by attempting to save the user wifi credentials and load it back after the patching is done.
If i remember correctly, it also checks and make sure the patch version is correct.
2.) I personally prefer CC3000 patch as it gave me better consistent results in terms of patching a core
3.) You can actually load your own user code but i personally load tinker after to make sure that the core is behaving properly and communicating with the well after the patch.
Tinker will definitely run well as a proven base firmware so that will not put us in the situation of “is it my code or the patch went wrong?”
After that is done, i will perform a USB or OTA flash with my user code.
4.) I rarely patch my cores nowadays unless something really wrong happened.
5.) Factory reset basically takes the tinker firmware saved in flash when is it factory programmed and replace the current user firmware. It also wipes out the wifi credentials too!
Let me know if you have more questions
This happen when with my code, but this is a code that was working great before.
I’ve got it working again. I reflashed it multiple times with the files (cc3000-patch-programmer.bin, spark_tinker.bin) downloaded from github as per your posting, but no joy. I also rebooted my router, factory reset several times, tried tethering to my phone, changed the USB cable, powered it directly from a USB plug, tried setting credentials from within the code, and waved it in the air in different orientations in case it was signal related. Still no joy. After using spark flash --usb cc3000 and spark flash --usb tinker it started working again. I guess there’s some important difference between the two cc3000 patches?
What 2 cc3000 patch are you referring to?
cc3000-patch-programmer.bin as downloaded from github and the patch applied by running ‘spark flash --usb cc3000’.
It’s the same thing
I was going to reply to say that they clearly weren’t the same thing because they were different sized files. However, I figured that if you said that they were the same thing then they must be … but if they were different sizes then that difference was significant. Then I had a hunch.
In your posting of April 9th above you said:
Download the patch from : https://github.com/spark/spark-cli/blob/master/binaries/cc3000-patch-programmer.bin
What I think I did was to use curl in a Linux command shell to download from that URL and then load using dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D cc3000-patch-programmer.bin.
On the face of it that seems OK. I followed the instructions?
The problem is that although the URL ends ‘.bin’ it is actually a web page so what I loaded in to my Core was HTML, so that why it didn’t work …