The same as in with the same out log or as in it compiles happily, The issue is that i2c is broken not that it would not compile.
By no dice I meant its giving me 0xFF over i2c
Ok let’s try to boil this down to super simple examples to find the issue… so with the MCP23017 button example I posted above do you just get 0xff returned from the mcp.digitalRead(0) call no matter the state of the 0 input (HIGH/LOW)?
As I said I don’t have an MCP23017, but do have a DS1307. By chance do you have one of those?
Hmm… also, you are using pull up resistors on your I2C_CLK and I2C_DATA lines right?
1 Like
Sadly I do not 
I Am using pull up resistors on my clock and data lines. Made that mistake the first time i played with i2c. (the code would also not work in the web ide if that was the case. Which it does) as for testing the button example it seems to not return anything useable it might be returning 255 but I am writing code to check now.
I made a minor edit to control the rgb led and it seems to not ever the led either? It is the first thing in setup so im at a loss.
ok, diving deeper into simplicity sounds like it might be the right next step:
#pragma SPARK_NO_PREPROCESSOR
#include "application.h"
void setup() {
pinMode(D7, OUTPUT);
}
void loop() {
digitalWrite(D7, !digitalRead(D7));
delay(500);
}
does it blink?
1 Like
No it doesnt… So now im wondering what actually is broken…
Ok cool, we’re on the trail of fixing things…
So this might be a good start, go into each of your libraries and do the follow commands:
core-firmware (aka firmware)
git checkout master
git pull
core-communication-lib
git checkout master
git pull
core-common-lib
git checkout master
git pull
You could also clone these all from scratch in a new folder to be absolutely sure you have a good copy of master
Then cd into the firmware/build/ directory and run make clean all and you should end up with the following build size (which is the tinker app):
Invoking: ARM GNU Print Size
arm-none-eabi-size --format=berkeley core-firmware.elf
text data bss dec hex filename
78908 1224 11860 91992 16758 core-firmware.elf
1 Like
So I did the above, And my sizes do not match up
arm-none-eabi-size --format=berkeley core-firmware.elf
text data bss dec hex filename
78776 1228 11864 91868 166dc core-firmware.elf
I just decided to clone fresh and try again and I got:
arm-none-eabi-size --format=berkeley core-firmware.elf
text data bss dec hex filename
78812 1224 11860 91896 166f8 core-firmware.elf
So I must have made a couple changes somewhere that I should have git stash'd
You are compiling on Windows with a different output than I’ve seen when I was compiling on Windows previously. Now I’m compiling on Mac with the following version:
>arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
What do you get when you type that in?
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Latest version available, Also going to say thanks in advanced. I just completely ran out of ideas on what is wrong. >.<
Ok in the name of science I just upgraded my toolchain:
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
now when performing a make clean all on current master I get:
Invoking: ARM GNU Print Size
arm-none-eabi-size --format=berkeley core-firmware.elf
text data bss dec hex filename
78768 1224 11860 91852 166cc core-firmware.elf
I’d say that’s close enough between windows and mac that we probably have the same code now.
I then ran make program-dfu with this build and it put Tinker on my Core. After testing with the iPhone Spark app I was able to toggle the D7 led no problem.
Would you please try this as well and see if you can get Tinker to work?
If yours doesn’t, give mine a try:
https://dl.dropboxusercontent.com/u/41117656/firmware/core-firmware.bin
You can flash it to your Core by going to the directory where you download it to, and typing:
dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin
Don’t give up!! We’re going to 
this problem in the 
2 Likes
I will say now I can not flash currently via DFU my install of DFU utils broke and I have fought with that to no avail. (I’ts a mix of me having done USB dev a few weeks ago and messing up my lib-usb install. And I just have not been willing to fight with it.)
I am going to install tinker, and let you know how it goes.
Also is d7 the user led? Or do I need to put one on d7 ( I have been manually checking it with my DMM because I was not sure)
EDIT: Tinker does work, User application is still not working.
EDIT2: also not giving up, I can not stand the webide, but to me my browser is a browser not a replacement for everything 
Tho it is nice for whipping up quick examples and finding libraries to use.
Hmm, so if dfu-util is not working for you… how are you compiling locally and getting that compiled binary onto your Core? Spark CLI?
I know we can get dfu-util working pretty easily for you…
Just drop the EXE from here into a folder like c:/dfu-util/dfu-util.exe and then add this ;c:/dfu-util/ to the end of your PATH Variable Value located in System / Advanced System Settings / Environmental Variables.
You also need the DFU UTIL driver (sounds like you know already but just pointing this out for all following along):
yeah spark-cli for all extensive purposes (make file pushes it for me via the api), It was working It’s been yelling that this device is not DFUable or not able to be looked up via vendor ID. I forget exactly but ill poke at it.
And yeah I know this already I was playing with LibUsb for an arduino project and borked everything
OK DFU flashing works again, User application code still does not work.
I’ll be back in a bit and think about it 
EDIT: Back! @Geekbozu So did you try to DFU the bin I linked up above, that should put Tinker on your Core and you should be able to turn on the D7 LED by setting D7 to a digital output and then setting it HIGH.
Sorry pinged you then had family stuff! Tinker runs from my local build flashed over cloud or DFU. Running a flash the led application how ever does not.
No worries!
Specifically, the Tinker that I supplied or can you also get the make clean all default build to work as well, which is also Tinker.
Make clean all does work ^^
So To clarify the current issues.
Building works. Running built applications seem to lose access to spark_wiring.
Tinker Does work. The wifi API features of the core do work with applications (the cloud connects and accepts flash requests)
i2c Does not work presumably from the fact that the spark_wiring is lost.
Hopefully that helps sum whats going on up @BDub
So this has been solved. Reason being that I had my source code in the wrong structure.
I moved my libraries to the Libraries Dir modified the Make file to include them. Added build.mk files for them and now it works.
Followed the instructions here and it solved everything.
2 Likes