Local Build - File was too big

I’m building locally, and everything has been going fine, but I’m getting very close to the flash limit. My understanding, both from the forum and the web IDE is that the limit is 108 kB (110592 Bytes), which can be calculated by adding the text size to the data size. The output of the build is:

Invoking: ARM GNU Print Size
arm-none-eabi-size --format=berkeley core-firmware.elf
   text	   data	    bss	    dec	    hex	filename
 108060	   1408	  14372	 123840	  1e3c0	core-firmware.elf

If I’m doing by math right, that should add up to 109468 B, or 99% of the flash. If I look at the actual core-firmware.bin file, it’s at 109472B. However, when uploading it via the CLI I get the Flash failed- File was too big error. Any ideas as to what my trouble is? Thanks!

This is the output for an empty sketch as per firmware 0.3.4

text	data	bss	dec	hex
75760	1224	11856	88840	15

In a nutshell:
Flash used	76984 / 110592	69.6 %
RAM used	13080 / 20480	63.9 %

Squeezing it to 99% is gonna be a problem i think :smiley:

Yeah, I know I’m pushing it. :stuck_out_tongue: Still working on getting it smaller. That still doesn’t explain why it should be within the limits but isn’t. I haven’t yet tried flashing via dfu, as I’d need to go get the spark out of the basement :slight_smile:

110592 sounds like the number that we calculated when this festure was worked on and 20Kb is a round number but it might be a few bytes larger here and there…

Those figures are correct. Can you say exactly how you are flashing the file to the core, and please copy+paste the error message. Thanks! :thumbsup:

I’m flashing using the spark-cli, and I just made sure that I’ve update to the most recent version. Exact command and response (with the id as XXs) is:

C:\Spark\Firmware\core-firmware\build>spark flash CorePrime core-firmware.bin
attempting to flash firmware to your core CorePrime
flash core said  {"ok":false,"errors":[{"id":"55ffXXXXXXXXXXXXXXXXX887","status"
:"Update failed - File was too big!"}]}

Thanks for your help!

Thanks for the info!

I investigated a little and found out you can emulate large files using the truncate linux/MinGW command

truncate -s 108K core-firmware.bin

This will extend the file (mine was 80k) up to the size specified.

I did this and got the same error as you (yay for reproducability!). I didn’t get a success until the file was at 105K. Which seems a bit odd, given the maximum truly is 108K (which I verified by flashing successfully via usb.) Pinging @Dave the cloud and spark-cli jedi master, he’ll know what’s up!

1 Like

Thanks for the investigation! Good to know that the usb flashing will still work. Guess I’ll make a trip to the basement after all :-P. Random guess would say that the issue is that somewhere a kilobyte is defined as 1000, not 1024, as 108*1000 bytes is 105.5 kB.

1 Like

Spot on - I just checked and see the maximum size is defined as 108000 bytes, rather than 108*1024 bytes.


Is that in the cloud software, or is that in the cli (so I could implement a temporary fix locally)? Thanks!

It’s in the cloud. I submitted a PR which has been merged, but I’m afraid I don’t know when this will be deployed. @Dave is the man in the know.

If you need a quick fix now, you might have some luck compiling locally and removing unused modules. Simply delete the .cpp file, e.g. tone, eeprom, i2c…anything that you are not using. If your code stops compiling, you can use git to restore the deleted file.

1 Like

how were you building locally?
I am caught in a circle of not being able to do it. What do you use to flash it locally

Hi @silashowe,

If you’re using the spark-cli ( https://github.com/spark/spark-cli ), you can flash locally with:

spark compile my_firmware.ino --saveTo my_firmware.bin
spark flash --usb my_firmware.bin


1 Like

@silashowe, I’m using the guide provided here for building using Netbeans: https://community.spark.io/t/how-to-video-for-compiling-locally-in-windows/2457. It’s a bit outdated, but generally should work. For flashing, you can either use what @Dave said, or use the dfu-util as outlined by the firmware repo. Also, I’d always assumed that the compiler stripped out unused calls automatically, so I wasn’t bothering to take out unused modules. Thanks for the tip @mdma! Reduced my size by about 5 kB!

1 Like

The compiler does strip out unused functions, but not data, and that causes some modules to be retained unnecessarily.