Web IDE Broken for larger projects?

So, I have a large-ish project that I’ve been successfully running on a few Cores for many months now. Changes to the project are ongoing and I just updated two of the Cores last week. All is well.

Today when I tried compiling the same code in the Web IDE I got a ‘FLASH’ overflowed by 667 bytes error. Cool, I guess the Web IDE is using the new HAL firmware base so, it takes up more space. I thought I could just remove some code and get it running again. Sadly, no. Even though I can “verify” the firmware ok after removing some code, clicking the lightning icon to flash it does not seem to do anything.

So, what’s happening? I tried flashing a very simple project from the Web IDE and it seems to work. But with no warnings or errors, it’s now impossible to figure out why the larger one is not working.

Does anyone have any suggestions? I know I should be a big boy and compile locally and flash over USB. Probably true, but that option is not ideal with my current hardware setup and I rather liked the Web IDE when it was working :smirk:

As a side note, when I open the settings panel inside the Web IDE it’s still showing that version 0.3.4 is being utilized. The one from October 21. So, is the supposed Web IDE update from Aug 6th really in effect and is what’s causing my issues or is something else in play here? Or is the Web IDE simply reporting the wrong version?

Any thoughts on this subject are greatly appreciated!

Thanks,
Alexander

Particle updated the compiler version on the cloud compile servers recently and it seems to cause the code to take a little bit more room in the flash.

Your line of thought is right: you can remove code or compile locally with a previous version of GCC.

This is terrible news! I have 20 some cores out in the field that we’re already at max capacity for memory and I need to flash new code to these to fix some bugs.

I am now stuck that I cant fix the one out in the field without loosing functionality of the devices by reducing file size by > 667 bytes!

Any suggestions to flash new code to these devices?

@wesner0019 I found that I was able to reduce my footprint by getting rid of inline text, as in Serial.print(“here is a nicely descriptive error that adds 100 bytes to the firmware size without doing anything”), but you may not have that issue. I also tend to use INTs all over the place whereas uint8_t would often suffice. But then again, if you’re already optimized on all those fronts, the only way around might be to compile locally. You can still do an OTA update with the resulting binary file using the Particle CLI.

Some more updates for anyone interested:

It seems that the flash ajax request returns an error, but the Web IDE is not showing it for some reason. If you open Dev Tools in your browser and watch the Network pane when you hit “flash” you will see that the request to https://api.particle.io/v1/devices/ will return:

{
  "cmd": "Event",
  "name": "Update",
  "message": "Update failed - File was too big!"
}

But the status bar in the Web IDE just goes back to “Ready.” This is definitely a bug for Particle folks to look at :wink:

1 Like

@akiesels, thanks I’ve had to remove my custom font to get the file size down enough.

You should report this as an issue in git hub.

I believe the team is aware of this issue, and is already working on something.

1 Like

Change the compiler option for optimization for size?

@stevech I am afraid the size optimization is already on by default (I see the -Os flag in the make output):

arm-none-eabi-g++ -g3 -gdwarf-2 -Os

So, yesterday I set up my machine to build/flash locally in the hopes to work around the Web IDE issues.

The same code that compiled and flashed ok last week compiles to about 115KB if I build off the latest firmware branch (targeting the Core, of course). This is about 7KB over the max size of 108KB.

If I work off master, the firmware compiles to about 109KB. Still too big to flash the Core either OTA or using dfu-util.

I was able to get it to work by taking out a significant part of the code, but it’s not really an acceptable solution.

What I am trying to understand is: what happened since last week when this same code would compile to under 108KB? What branch can I build off to make this work again? There are 58 branches for the firmware repo in GitHub, so I would like to avoid figuring this out by trial and error.

Can anyone comment on this?

Thanks,
Alexander