I received my Core a couple of days ago, and upon powering and configuring it, right after it went to the magenta upgrading firmware phase, the firmware got corrupted (flashing yellow). With the help of Spark employees on the IRC I was able to flash the newest firmware via USB, and it all went well, Tinker worked and I could change pin states via the terminal even. But the minute I try uploading something through Build, it gets corrupted again and I need to reflash manually. Is this happening with anybody else? Does anyone know how to fix this?
Hello @henriquepss
Sometimes the Core does fail to program via the cloud, but not always. It will depend on several factors like your signal strength, internet connectivity, etc. We are working on improving the consistency. Have you had no luck at all upon trying a few more times?
Hey @mohit
I think I tried 3 times in total. My computer broke so I wasn’t able to reflash it since. I’m away from home and will run the test more times to be extra sure when I get back. But is it normal, when the core fails to program, to end up with a broken firmware that isn’t restored when I factory reset, continues to be corrupt?
Ideally when the OTA fails, the Core should revert back to the factory reset firmware (Tinker). It is unusual that it goes into a DFU mode. This can only happen when the factory reset firmware itself was corrupted to begin with.
So, when the OTA fails, are you able to put the Core in the factory reset mode manually? or do you have to flash it over the USB everytime?
Have to flash over USB everytime. Nothing happens when I reset.
This is exactly the same behavior I’m getting, posted here with a similar video.
The difference is that when I re flash the factory firmware the core enters in the normal “light cycle”:
Flashing blue > Flashing green > Flashing cyan > Flashing magenta > Stuck at yellow flashing
After flashing magenta for a long time (~5 minutes), it’s starts flashing yellow again, like my video and @henriquepss video’s, every single time.
Already sended and email to spark core team and waiting for response, and also favorited this topic 
1 Like
Yep, exactly what happens to me as well. @flatlining, were you able to program the core via USB and have it work with the Cloud? I know Tinker works no problem if I don’t flash something new.
Nops, since it flashes cyan it registered itself in the cloud, but was not able to use the tinker since after flashing magente (update) it goes to flashing yellow.
But you are able to reflash it via USB, right? When I do, Tinker actually works.
@mohit, any updates on this? =S
I learned today how to compile the firmware code, and am now able to flash my applications over USB, which renders my Core somewhat useful. In the mean time, I did some testing. Any time I factory reset, regardless of my Core having a bad current firmware or not, it becomes corrupt and enters DFU. That means whatever is on 0x20000 at the external flash isn’t something that was supposed to be there. So if this is truly a factory reset, either something didn’t go well in manufacturing or I have a bad external flash.
When I receive OTA firmwares, as when I flash through Build, they should go to 0x60000 at the external flash, but that isn’t going well either, and I assume that it doesn’t need, at any time, to read factory firmware information, which adds to my assumption that I have a bad flash. This assumption is fairly easy to test: currently you don’t have an user accessible library to drive the flash, but it’s SPI, so I’d guess it shouldn’t be hard to either write in the user reserved section of the memory or even fix the factory firmware if the flash is fine. I just need to know how, in the code, to select the SMT32 pin responsible for the SPI bus of the flash.
If I’m not able to write something where I’m supposed to in the flash, I’ll let you know.
Also, if you haven’t been able to understand what is happening to my core because of my lack of clarification skills, this video should help out. This one, that I already posted, shows what happens on factory reset.
Hey @henriquepss
Just wanted to check, not sure if we tried this earlier, if you wanted, you could replace the contents of your factory reset area:
dfu-util -d 1d50:607f -a 1 -s 0x00020000 -v -D core-firmware.bin
dfu-util -d 1d50:607f -a 1 -s 0x00020000:sizecount -v -U temp.bin
You could try flashing that, and then reading it back out. If those don’t match then you probably have a bad flash chip. Make sure to specify the size when reading it back out.
Thanks!
David
@Dave, look what happened when I tried the first command:
This was the end:
Thinking all these timeouts shouldn’t be happening, right?
Hi @henriquepss,
I wouldn’t worry about those just yet, we added the “-v” verbose flag, so if it still said successful at the end that makes me think it worked. I would be more curious about the comparison between the two. If they match, but a factory reset still fails, it’s possible we have some code somewhere that isn’t waiting long enough on slow flash chips or something – I’m guessing here slightly since @satishgn and @mohit know more about the hardware than I do.
Sorry for the radio silence, @Dave. Some real life stuff got in the way and I couldn’t do much testing, but now I have some time.
When I run the second command, I get a “Error: Invalid dfuse modifier: sizecount”, running dfu-util 0.7:
Ah sorry, replace “sizecount” with a number of bytes around the size you want to pull down, so something like:
dfu-util -d 1d50:607f -a 1 -s 0x00020000:70000 -v -U temp.bin
Will grab the firmware in a 70k file with some extra junk on the end.
Thanks!
David
Oops, didn’t interpret well what you said and thought sizecount was part of the command. Sorry about that. I did a du -b core-firmware.bin and put that in the command, so I could theoretically get the exact same file and could just compare hashes. They’re different :S
1 Like
So that was the core-firmware we just wrote to there earlier in the thread, and the download you just got back? Welp! That sure sounds like a bad external flash chip!
Thank you for helping troubleshoot / confirm this, if you haven’t already, can you email us at hello@spark.io and we’ll get started on sending you a replacement asap?
Thanks!
David
Well, this sucks. Thanks for all the help, you’ve been fantastic with your support. I’m betting @flatlining also has a bad flash chip, they should email you too!