Bug bounty: Kill the 'Cyan flash of death'

Firmware
367

@sjunnesson @bkize

I just built the release version with my tools stream CodeSourcery and it runs fine on my core. So the questions is what is the difference?

To that end http://nscdg.com/spark/spark_new_master_core-firmware.zip has 2 builds of my test application.cpp
(as of c5da467fc3cc641ee538208eb819ec43c9cf6d4c ) one debug the other release.

@sjunnesson @bkize would you load these and see it the issue persists?

@Frido What tools and command line did you use?

@BDub and @mohit Would you have time to see what results you get from a build of the branch?

In the mean time I will build an dev environment from the core-firmeware instructions and see if I can figure out the difference.

Thank you all for you help.

David

2 Likes
368

Just the default toolchain for OSX as described on https://gist.github.com/joegoggins/7763637

ran my shellscript (mentioned earlier), copied the appplication.cpp for my LCD to /src and ran ā€˜makeā€™ from /build

flashed with dfu-util

nothing specialā€¦

Being happy with :spark: up for 115622 sec,

Frido.

369

basically I followed @Frido description earlier to checkout the repo

rm -rf git_master_new
mkdir git_master_new
cd git_master_new
git clone https://github.com/davids5/core-firmware.git
git clone https://github.com/davids5/core-common-lib.git
git clone https://github.com/spark/core-communication-lib.git
cd core-firmware
git checkout spark_master_new
cd ../core-common-lib
git checkout spark_master_new

then build and deploy with normal toolchain

make
dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

Im using this version of gcc

gcc-arm-none-eabi-4_8-2013q4
370

@Frido Thank you for the feedback.

FYI @sjunnesson, @bkize, @BDub @mohit

I just finished a build with GNU Tools Arm Embedded (4.8 2013q4) on Win 32 per the core-firmware and I get the read flash.

It is a PANIC out of heap! So the I suspect that CodeSoucery does a better job of coalescing

In release mode the IWDT (wtach dog) is cutting short the SOS and blink codes. :frowning:

In debug the output on tx,rx (3.3V) pin is a <PANIC> char* _sbrk(int) (139):Out Of Heap

0000000001:<DEBUG> int main() (103):Hello from Spark!
0000001994:<DEBUG> int Spark_Connect() (616):sparkSocket Now =-1
0000002000:<DEBUG> int Spark_Disconnect() (654):
0000002004:<DEBUG> set_socket_active_status (810):Sd=0, Status SOCKET_STATUS_ACTIVE
0000002012:<DEBUG> int Spark_Connect() (623):socketed sparkSocket=0
0000002018:<DEBUG> int Spark_Connect() (644):connect
0000002164:<DEBUG> int Spark_Connect() (646):connected connect=0
0000002306:<DEBUG> int Spark_Receive(unsigned char*, int) (366):bytes_received 40
0000002314:<PANIC> char* _sbrk(int) (139):Out Of Heap

Let me see what is causing it.

371

Found the issue!

FYI @sjunnesson, @bkize, @BDub @mohit @zach @zachary

As indicated here https://community.spark.io/t/bug-bounty-kill-the-cyan-flash-of-death/1322/370

There is a significant memory usage difference when building with the two different tool streams.

The fix for the GNU Tools Arm Embedded (4.8 2013q4) on Win 32 build was to add an #ifdef and #ifdef out out the first UDP object and itā€™s code in my test app. (So under GCC the test app only does a UDP receive and and HTTP get)

This has been pushed to https://github.com/davids5/core-firmware.git

both the debug and release builds are running on my code using the DFU.

372

@david_s5 Thanks for the quick turnaround. Iā€™ll test your latest spark_master_new branch later today.

Like @sjunnesson, Iā€™m running the Spark-recommended compiler: arm-none-eabi-gcc 4.8.3 20131129. Iā€™m curious about a better ARM toolset if itā€™s in the sub-$250 range but thatā€™s another topic.

Just a bit ago, I built the latest master branch from Spark - the last merge was ā€œtechnobly/spi_fixesā€ - and it seems very stable. I built that branch earlier this week and it was a blink-fest so I had to revert to the compile-server2 branch.

@zach Great to hear about the progress with TI.

373

@bkize The spark master has some of my spark_master_new in it so I would expect it to be more stable. Once the Pull Request get in there it should match spark_master_new plus any other great fixes that have been submitted.

374

thanks for the update @david_s5 The new code flashed nicely and is now loaded on 4 Cores here that I will leave for a week to see how they go. Hopefully when I get back from my trip they all will breath happily and still report to the cloud.

375

@david_s5 Your updated spark_master_new branch is looking good so far. No issues whatsoever.

Yes, Iā€™ve been monitoring the commits to the Spark core-* repositories. Kudos to you for all of your contributions. The next major firmware release by Spark should be significantly better with all of the contributions from the community plus the many improvements made by the Spark team. Great progress a short timeframe.

376

@david_s5 I tried to run make via command line but it gives me the following error probably because Iā€™m setup with GNU Tools instead of what your using.

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