Hi there. Just got my Photon and weather shield from SparkFun, and I’m having a perplexing problem with Particle Dev. I’m running it on a Mac OS X system. Got the Photon configured easily, installed the Tinker app on the iPhone (it works to talk to the Photon), and tried to build one of the sample programs from the weather shield GitHup repo.
When I try to build and look for errors, the IDE just says “build didn’t produce a binary” but there’s no information about what’s wrong.
I tried the I2C Address Scanner and the weather basics, and I’m seeing the same behavior. This must be something stupid I’m doing because I don’t have experience or understanding of some key concept because I don’t see it mentioned anywhere on this forum, and Google returns nothing.
If there’s more information needed, let me know and I’ll be delighted to provide it! I just would rather not chuck the Photon and weather shield in the parts bin because I can’t get cloud compiling to work. But I’m really stuck.
@bko Bingo! Nice call! I looked at the permissions and ownerships on othe .DS_Store files to make sure I got it right (can you tell my background has UNIX Systems Programming in it?), then created the file in both the project directory and in the root directory. Then I restarted Particle Dev. Now I’m getting a programming error (Module has no member “sleep”), but I can work with that! Thank you so much for the help! I really, really appreciate it!
Oops. I typed too soon. Now it’s back to the “build didn’t produce binary,” even though I have a .DS_Store file in each directory. I’m again suspicious that I’m missing something in the configuration, since the build couldn’t find the module “sleep” in the System class (i.e., “System.sleep(…)” throws an error.
You need to have the particle.ignore file in each directory you build in. Inside that text file should be a line with .ds_store and any other files you need to ignore. The .ds_store file is added to each directory automatically when needed in OS X so you should not create or change them normally. If you open up a shell in the Terminal program in OS X and cd to the directory with your files, you can then use ls -a to see all the files there including the hidden files like .ds_store.
I’m suddenly having the same error compiling code I haven’t changed. I have no .ds_store file in the dir, and I added a particle.ignore specifying it just in case. I’ve quit & restarted the Particle IDE. I’ve logged out/back into my account. I’m on the latest version.
Looking at the Particle.io System Status page, I see this from 9/11:
“We rolled out some new firmware options to the build farm today, so there were a few minutes of compiler interruptions, sorry! Should be fine now.”
Later the eve 9/11 is when this error started happening to me.
So… did something break on the server side? Like I said - previously compiling code now won’t compile.
@suda do you know? One more piece of info: if I induce compile errors, they show up. So the compiler does seem to be running against my project. But without compile errors (my code was compiling fine prior), I’m guessing something is going wrong post-compile/linking where this is happening:
@jdr, just to make sure, when you say Particle IDE you mean Particle Dev?
Next you have definetly checked that there are no files what-soever in the path you are building from than the ones that need to be compiled into your project (only maximum one.INO file and .h/.cpp files - unless explicitly stated in the particle.ignore file)?
Thanks @LukeUSMC and @ScruffR. The command line compile showed me the issue, which points to a change in the underlying Particle firmware. Looks like more HAL-related refactoring and the change finally hit the Core firmware (I’m using a Core in this project, not a Photon).
There used to be an exported C function pointer called Wiring_TIM2_Interrupt_Handler that you could override to hook into the TIM2 timer on the Core (STM32). I was using it as the basis for a timing library I wrote. Turns out, code was recently changed to rename it to HAL_TIM2_Handler. I went into the Github repository to confirm. Lines 48-50 in here (https://github.com/spark/firmware/blob/f381b65a5b2cc06513eaa338b03b9351bf468e8d/hal/src/core/tone_hal.c) tipped it off, since the Tone library uses it as well.
Anyway, I fixed my code to hook into the renamed export and now it’s all working again. Was a linking error:
/tmp/ccrctwKy.ltrans25.ltrans.o: In function __static_initialization_and_destruction_0': WSNGateway.cpp:18: undefined reference toWiring_TIM2_Interrupt_Handler’
collect2: error: ld returned 1 exit status
I’m on Mac/OSX. I created a folder structure:
~/ParticleProjects
~/ParticleProjects/Firmware1
~/ParticleProjects/Firmware2
The latter 2 folders contain my respective .ino file as well a particle.ignore and particle.include file. The ~/ParticleProjects contains a particle.ignore file.
My particle.ignore files contain:
.DS_Store
My particle.include files contain:
firmware1.ino (firmware1 folder)
firmware2.ino (firmware2 folder)
Building any of my .ino files gives me this “build didn’t produce binary” message.
If I have only 1 .ino firmware file in the ~/ParticleProjects folder I can successfully build a binary.
The Particle Dev builds only the current folder as far I know. It should work if you build in Firmware1 or Firmware2 but not in the upper level.
Also you can only have one .ino per project–all the other files should be .h/.cpp. These will not have the preprocessor applied so you have to follow normal C/C++ rules, not the relaxed Arduino-style Wiring rules.
I am struggling with some code, and occasionally get the ’ build didn’t produce binary '. One minuite it does, next it doesn’t and I’m continuously commenting out code to see where it goes wrong, then… I’m back at supposedly the code that worked earlier yet still it didn’t produce a binary.
Then I noticed that I had no devices selected. Bear in mind Im not trying to flash, just compile in cloud and show for errors - all done in Particle Dev.
As soon as I selected a device, the exact same code then succeeded.
Note also that the compile buttons do not do a save before compiling - this had me fooled for a while.
Just something to watch out for as I don’t know if its a requirement to have a device selected before doing a compile.
Yes it is required for the build farm to know what modules to use for the build.
Some things might not be available on one platform that are available on another (e.g. DAC does not exist for Core).
I guess we know that Particle Dev is still in development so we can expect a few hiccups. Everything was going fine and then I got the dreaded
`"(!) build didn’t produce binary Error: Command…"
If I clicked on it, it reported at the top of the page:
"There were no compile errors"
It was a large file and I wasted a bunch of time; eventually, as suggested above, I used the command line compile which helped identify a typo.
I managed to replicate the phenomenon in a small file, as follows:
// Function prototypes
int myFunction(String foo);
void setup() {
Serial.begin(115200);
Particle.function("myFunction", myFunction);
}
void loop() {
}
int aFunction(String foo) {
Serial.println(foo);
return 1;
}
Note the “typo”: myFunction(), listed as a function prototype, doesn’t match aFunction() declared later. It works of course if aFunction() is changed to myFunction().
The point is that Particle Dev won’t build a binary but doesn’t find an error. How do I flag this for the development guys?
My advice to others is that if you get a “build didn’t produce a binary” go immediately to command line compile for extensive warnings and error messages.
Can anyone explain in normal English in basic steps how to fix this error?
I’ve tried to understand all that you guys are saying but I haven’t been able to do it. Something about add files that state which files to ignore? So I make a txt file called “particle.ignore” where it says “.ds_store” inside? All I have in my folder is the .ino, a .cpp and a .h file.
Had the same error when using windows IDE, when using CLI compiler like suggested found the real problem (that compile output contained the information I needed to solve my coding error).
Guys @ particle @Zamburak , please forward all errors from compiler to windows UI, this might take a newby ages to solve / find.
So in summary -> if you want some actual useful output run this command in cmd.exe in the folder containing the (your project name here).ino (assuming you have this complete enviroment installed). It should look like this:
Was a linking error: