Error: Could not compile. Please review your code. ---Even for example code---

Cloud
1

Anyone else having trouble with the WebIDE build process?

This started around 11pm last night (PST), I figured it was just a hiccup or maintenance issue on the servers. Tried again this morning, same error.

Tried:
-Building the Blink LED example, same results.
-Three different browsers, including chrome incognito (saw someone suggest that in other posts), same results
-Sleeping it off, same results

Coffee is brewing, trying that next…

1 Like
2

Have you checked if you got a correct target device selected?

I’ve been building yesterday and today without problems.

3

Only have one Photon device linked/connected currently, shows up correctly in my Particle Devices.

It was all working fine last night for a few hours, then on one “Verify” click it stopped building and I seemingly cannot build any projects now/since.

4

Hi @newt80ns,

Can you tell me the device id that you’re building for?

Thanks!
David

5

ID: 3e0026000347343339373536

Though I think I found to root cause. I was adding a large number of cloud functions and variables last night while testing. I had ~18 unique Particle.variable(), and 7 Particle.function () calls (I’m aware this is over the documented limit). This firmware compiled, flashed, and worked as intended.

However, subsequent builds would fail, no matter what I tried.

This morning I setup a local build/flash environment, so I could get some work done w/o relying on the cloud IDE. Once I flashed a default firmware back to the device all of a sudden my cloud IDE was building again, and I could reflash from the cloud, odd… However, once my firmware from last night was running again, no more cloud building… As soon as my firmware is loaded onto the device the cloud building fails.

It’s not the end of the world, I can simply flash the tinker firmware to the device when I need to build/flash my code, but there’s something build system that either shouldn’t be allowing my large number of variables/functions to compile and execute, or cleanly handle the larger number of exposed variables/functions.

Thanks all for the quick replies and suggestions!

6

A developer should not rely on the compiler to check for things like this.
There are tons of errors that will perfectly build but brake your application, since they are syntactic correct.

It’s just like writing this and expecting the compiler to complain


char shortString[1];

void setup()
{
  int a = 10;
  int b = 0;
  int c;
  strcpy(shortString, "This will build but most likely cause problems");

  c = a / b; // builds but will crash the app  
}
7

Hi @newt80ns,

Ahh yes this makes sense. I recently discovered this bug in the firmware that prevents the device from sending a list of current system modules (when you have huge numbers of functions and variables). This triggers a bug in the compiler while it’s trying to figure out if it should package an update with the new firmware. On my list of things to fix! :slight_smile:

Thanks,
David

8

Oh, I completely agree, sorry didn’t mean the compiler needed to sanity check everything!

In this case the code compiles, executes, and operates exactly as expected, until the rebuild/flash process.

2 Likes
9

Dave, appears like that’s exactly the case, thank you!

Sounds like I’m not the first trying to expose a large number of functions/variables… so, what is the limit/max? :wink:

I’m just framing out the interface now, and honestly hadn’t seen the variable and function limits until I was a bit far in last night. In my testing it was all working fine, so I soldiered on.

1 Like