I’m available to help get you going this morning. You can email me directly at david@spark.io, and we can dive in more deeply if you want. It looks like you ran the patch programmer successfully which is cool.
I know there was a bug briefly that made it hard to get cores on networks without passwords. So if you wanted to try a workaround you could grab TI’s SmartConfig app which I know handles blank passwords properly. Or, just to rule out possibilities, you could throw a WPA2 password on your airport extreme, and try using that one. I have an airport extreme at home and it works well for my core.
This is also maybe a silly question, but you have chip antenna and not a u.fl core? I have definitely forgotten to attach an antenna when testing u.fl cores.
Can someone point a direct link to the dfu-util binaries for Windows? Even better would be if someone could compile a single list of the binaries for all of these things. I’ve wasted too much time already trying to get this device working.
Yea I noticed that too, if I had it in listen mode and it went out of listen mode it doesn’t tear down the serial connection properly and my computer still thinks it exists.
The trickiest parts are installing WinUSB drivers for the core in dfu mode first using something like Zadig, and then making sure you run dfu-util from an admin command prompt. I’ll also be online for a while longer tonight if you wanted to email me at david@spark.io if you run into issues.
I’ve tried the latest cc3000 firmware, and that didn’t seem to fix my issue, and I’ve tried updating the firmware on the core itself and that didn’t seem to fix the issue.
Here’s the network I’m trying to connect to via airport -s
LM 98:fc:11:97:be:76 -29 6 N -- WEP
I’m still sitting stuck with a flashing green light.
I’ve been setting the SSID and password with screen /dev/tty.usb1421.
Cool, thanks for posting your AP info, that’ll help when we are communicating with TI. Based on this thread, it sounds like some people have had problems with WEP protected networks. Could you try Smart Config`ing with TI’s SmartConfig app, or try switching your network to WPA2 temporarily to see if that gets your core online?
Dave, thanks. I’ve made some progress. I believe I have the patch applied. However, I’m not sure what to do now. After applying the patch it stopped blinking magenta then went to solid magenta. Now upon reset it doesn’t blink anything. Only the tiny blue LED is lit. No devices show up that I can try to terminal into. Holding down the mode button only restarts the patch update again. What next?
@ianlee you need to do a factory reset by holding MODE for 10 seconds while turning on the Core (either plugging it in over USB or hitting the RESET button). this should start the LED flashing white, and then your original firmware will be re-installed.
Alternatively I found that flashing it with the latest code from core-firmware worked too. I’m honestly not 100% sure what factory reset means, does that reset to the firmware that was on it when I bought it or the last firmware that was updated automatically. How does that work?
@zach Thanks. That got me back to blinking. I setup the SSID again via USB and now I’m back where I started. It just blinks green. I’m on an open network. What else can I try?
@ianlee74 There’s an issue with setting up open networks via USB in the factory reset firmware. As @nixpulvis pointed out, if you use dfu-util to flash the latest build/core-firmware.bin from the core-firmware repo, then setting up the SSID via USB will recognize the open network.
I added open networks to the USB Wi-Fi setup process on Thursday. Otherwise, it currently assumes WPA2. Expect the addition of other security options like WEP this week—it’s on my sprint. Thus, for now, adding a WPA2 password to your network is another thing that may get your Core online, just for testing.
Also, if you have an iOS device, the Smart Config app from TI handles open networks correctly. Ditto Android, but it’s not in the Play Store, you have to get the .apk from TI’s website.
@nixpulvis factory reset right now literally does mean resetting the Core to the firmware we programmed at the factory. Thus, after a factory reset, the Core will get an auto-update the first time it connects to the server.
We’re probably going to upgrade the “factory reset” firmware in the next couple months to not roll so far back, but as you can imagine we have to be careful about that.
Hi Zachary and team,
II have two Spark Cores and neither of them will connect to our network. Out of the box, both cores got stuck on the flashing green. So I read through this thread and tried the cc3000 patch progammer solution. I’m on a Windows machine. I seem to be able to run this command without issue: dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D cc3000-patch-programmer.bin,
and then the following 2 steps seems to work:
When the Patch Programmer is installed, the LED should turn off. Press the MODE button for one second to install the Patch; the LED should start flashing magenta.
When the patch has been successfully installed, the LED will switch to solid magenta.
So, yeah, I can get here, but I’m failing on the following step:
To reboot back into the Spark Core standard firmware, hold the MODE button for 10 seconds while the Core is powering up (as above, to get into bootloader mode). This will activate a factory reset; if it is successful, the LED will flash white, and then the Core will return to its previous state (but with new firmware on the CC3000).
I’ve had two different things happen after doing step3: I’ve had a flashing yellow LED, and I’ve had a solid magenta LED. I am than rebooting into (what I think is) bootloader mode, at which point I get the flashing yellow/green-ish LED. This is where I get stuck.
When going through this series of steps, I end up stuck back at flashing yellow-green-ish LED.
EDIT: I then install the factory_firmware.bin, and get back to a flashing blue. However, I am still unable to get my core to connect to WiFi. Stuck at flashing green LED again.
Okay, it sounds like you successfully re-patched your core, and loaded the firmware back on. It’s important to keep in mind only a very small number of cores (less than 1%) left the factory without this patch, but it’s a valid precaution while troubleshooting this issue (and it doesn’t hurt anything).
Can you email me at david@spark.io, and we can check your networking setup and configuration?
I’m going to try to patch, but I’m having a hold up downloading the gcc tool-chain in Mint Linux 14
E: Unable to locate package gcc-arm-none-eabi
This message is after I add the repo.
I also to tried manually install but I’m not sure how to build it after uncompressing the tar ball. The read.me left that part out.
I just spent an hour trying to solve the same issue as the topic starter. In the end, I was able to resolve it by setting my wireless AP to another channel number (10).
I honestly am just trying to figure this out from a lay user perspective, following instructions in the readmes.
The patching utility fails to “make all” without it
Building file: ../startup/startup_stm32f10x_md.S
Invoking: ARM Sourcery Windows GCC Assembler
arm-none-eabi-gcc -x assembler-with-cpp -Wall -c -fmessage-length=0 -MMD -MP -MF"startup/startup_stm32f10x_md.d" -MT"startup/startup_stm32f10x_md.d" -mcpu=cortex-m3 -mthumb -g3 -gdwarf-2 -o "startup/startup_stm32f10x_md.o" "../startup/startup_stm32f10x_md.S"
/bin/sh: 1: arm-none-eabi-gcc: not found
make: *** [startup/startup_stm32f10x_md.o] Error 127
