Bug bounty: Kill the 'Cyan flash of death'

Firmware
377

Hi RWB,

The temporary solution to that for Windows 7 can be found on this post - https://community.spark.io/t/error-building-firmware-on-windows-7/1301

You have to replace “rm” and “mkdir” syntax in all the "makefile"s. The makefiles can be found in the “build” folder of all the repositories - core-firmware, core-communication-lib, core-common-lib.

Before:

RM = rm -f
MKDIR = mkdir -p

After:

#RM = rm -f
#MKDIR = mkdir -p
RM = "C:\Program Files (x86)\Git\bin\mkdir.exe" -f
MKDIR = "C:\Program Files (x86)\Git\bin\mkdir.exe" -p
378

@RWB If you have GitHub for Windows installed - which I highly recommend - see another option here:

Bottom line: Use the “Git Shell” app/shortcut to open a Git-aware command line that recognizes the commands above, instead of opening a “normal” command line that does not.

379

@RWB Try editing your path to pull in the location of make then git, gnutools.

Also use dir /X and get the 8.3 name of your “Program Files” folder it will look like PROGRA~1 and use that in your path.

To persist the path user “advanced setting” ->Advanced Tab->Environment Varables Button.

Close and reopen any cmd/shell windows/

Here is the Win 7 32 path I set up that worked.

PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\PROGRA~1\GnuWin32\bin;C:\Program Files\Git\cmd;C:\PROGRA~1\Git\bin;C:\Program Files\GNU Tools ARM Embedded\4.8 2013q4\bin

380

@david_s5 you just saved me a lot of time by getting me to try to fix my build situation. I had a problem where if I ran “make” from the build directory once, it worked. But if I ran it again it was failing. This was because of some file paths in some of the .d files. I was thinking maybe converting my PATH to DOS8.3 format would maybe change the situation… worth a try at least. So I did, and it was now building over and over perfectly. But as a test, I put my PATH back to the normal long version expecting it to break again but it did not. Still builds perfectly. There must have been some updates to the make file that I wasn’t aware of… so thanks for inadvertently saving me a ton of time! I had to basically clean all build directories before EACH build prior to now… that really sucked.

381

@Bdub I had the same issue. I was able to run the Make via command prompt to load your firmware just fine the first time but when I tried to run it later via command prompt I just keep getting this error:

Others gave me links to ways to fix this but it didn’t and after 2 hours I gave up.

I tried to load your Firmware again but it would not compile either and gave me the same error message even though it worked the first time. I just figured the Communication-lib had been updated and that was causing the error message.

In frustration I just deleted all the programs needed to compile and figured I would start from scratch and try again.

So what exactly did you change to make it work again? Should this also work for me? I would like to try out David_s5’s latest firmware but can’t flash any new firmware because of this issue.

382

I was actually getting a totally different error before, you can read about it here (and many posts after this one):

I’m building from the same code you are if you cloned my “watchdog_timer_fix” code… so it must be a difference in how our systems are set up.

My path is as follows:

C:\Program Files\GNU Tools ARM Embedded\4.7 2013q2\bin;C:\Program Files\GNU Tools ARM Embedded\4.7 2013q2\arm-none-eabi\include;C:\Program Files\GNU Tools ARM Embedded\4.7 2013q2\lib\gcc\arm-none-eabi\4.7.4\include;C:\Program Files\GnuWin32\bin;C:\Spark\dfu-util-0.7
383

@BDub did you close the dos windows in between?

384

Yes, and it still works great with the long path names… good too, because I don’t like to revert to 1995 much :wink:

385

@david_s5 I can also report in happy Cores running for ~2 days soon. So the firmware seems to stand up for the test so far. I will be gone for 5 more days and hopefully when I come back they all will keep on breathing.

386

Fantastic! - The code is noW (typo fixed) merged into spark/master

387

That means that its not yet part of the stock firmware that is loaded via the Web Based IDE right?

388

It was a typo it is now merged into spark/master Yes it has not been pushed to the branch the webIDE builds from but I expect it will shortly

389

@david_s5 Right. I was about to ask you about your earlier comment since it looks like they’ve now merged all your pull requests. :slight_smile: Good work and thanks. You’ve made a lot of great contributions and fixes.

@RWB I think the Spark team stated a while ago that the branch of code pushed out to Cores and the IDE is compile-server2. Right now, that branch is almost 100 changes behind the master branch. I’m sure they’ll post to the blog once they release a firmware update.

390

Thanks for the info. It seems the Web IDE firmware is running alittle better now than id did 2 weeks ago when I last ran it. Not sure if its the same or not.

391

The Web IDE is not running any more for me and I’m unable to use Eclipse to build the firmware anymore.

I’m experiencing a slow flashing blue led before the cloud starts flashing the firmware… whenever it manages to do it…

392

@rlogiacco I started a new thread for this, because it seems to be unrelated to CFOD:

393

Great news, everyone! From Texas Instruments:

When we receive the patch we’ll share it with the community ASAP, but be forewarned: use at your own risk until it has been tested by the Spark team!

11 Likes
394

This is awexome and very promising :slight_smile:

395

Alright - This is great news!

@BDub have you tested master lately? Is the recovery working well?

396

@David_s5 I’m running the latest IDE firmware and it seems alot more stable than before. It does not freeze up near as often as the old Firmware did. Not sure what changes were made but things seem to be better.

I have not had time to try you latest firmware though.

Great news from TI… Were getting closer to Stable :smile: