SOS out of heap (8 flashes) building from cloud

Troubleshooting
1

I’ve build my code locally and it has been working fine.

   text	   data	    bss	    dec	    hex	filename
  84364	    716	  12288	  97368	  17c58	core-firmware.elf

When I build from the cloud and flash, the core immediately SOS’s on reset (I don’t even see a white light.) Here’s the stats from the IDE:

text	 data	 bss	 dec	 hex
84736	716	12480	97932	17

In a nutshell:
Flash used	85452 / 110592	77.3 %
RAM used	13196 / 20480	64.4 %

The figures look pretty much the same, yet the cloud compiled sketch fails while the locally compiled one works fine.

Any ideas?

2

Hmm, that’s weird. We just released the ram optimization firmware improvements to the build farm yesterday, so it should have at least 4K of ram during startup / handshake, and about 12k of available dynamic ram while connected to the cloud. Any chance you can post your code?

Thanks!
David

1 Like
3

The code is online in a library. To get it, please add the flashee-eeprom library to a app, and copy the integration-test.cpp example to your app. Because of the preprocessor issues I was having, most of the code currently lives in the header integration-tests.h in the library.

I’m afraid it’s not trivial code, and I’m not sure how to water it down or even debug it since the sources aren’t local once I’ve built in the cloud.

Anything I can do to help, just let me know.

1 Like
4

I’ve tried to par it down to a smaller example case:

#include "application.h"

#include "flashee-eeprom/flashee-eeprom.h"

using namespace Flashee;

void setup()
{
    Serial.begin(9600);
}

void loop()
{
}

What’s strange is that the flash library uses dynamic memory allocation and it’s not even invoked. Yet, the Spark flashes red immediately on startup (before wifi connect etc…)

The library does have a static initializer - see Devices::userFlash, which allocates an object to manage the user accessible flash region, but it’s only a handful of bytes in size.

I have compiled identical code in the IDE and locally and can confirm the local code compiles and runs.

1 Like
5

Hi @mdma,

Cool, yup! Reproduced on my end as well. I’ll dig into this and report back with my findings when I can, it might take me a few days.

edit: haven’t dug in yet, but I’m guessing some example file or other file is being wrongly included that maybe uses too much ram.

Thanks!
David

3 Likes
6

Hi @dave - any news? @stevespark is also getting the same problem. It it’s something I’ve done wrong with the library I’d love to know so I can fix it, but it’s working fine locally. (I should also try the CLI to see if that helps, but I have no time to try that until tomorrow.)

7

I’ll look into this now, I don’t want to block people from using this lib at all, back in a few.

Thanks!
David

8

wow, I appreciate that, after all It’s the weekend! you should be taking it easy!

9

Okay, I’ve been looking into this a bit, I haven’t found any obvious issues on the server end, but I did fix a few small bugs. I’m having trouble compiling the library locally:

In file included from ../src/flashee-eeprom/flashee-eeprom.h:154:0,
                 from ../src/application.cpp:5:
../src/flashee-eeprom/flashee-eeprom-impl.h: In member function 'virtual bool Flashee::SparkExternalFlashDevice::writePage(const void*, Flashee::flash_addr_t, Flashee::page_size_t)':
../src/flashee-eeprom/flashee-eeprom-impl.h:1309:66: error: invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'uint8_t* {aka unsigned char*}' [-fpermissive]
In file included from ../../core-common-lib/SPARK_Firmware_Driver/inc/hw_config.h:34:0,
                 from ../inc/main.h:37,
                 from ../inc/spark_utilities.h:30,
                 from ../inc/spark_wiring.h:34,
                 from ../inc/application.h:29,
                 from ../src/application.cpp:3:
../../core-common-lib/SPARK_Firmware_Driver/inc/sst25vf_spi.h:65:6: error:   initializing argument 1 of 'void sFLASH_WriteBuffer(uint8_t*, uint32_t, uint32_t)' [-fpermissive]
1 Like
10

Hi @Dave,

The compile error is because the library is expecting sFLASH_Write to take a const pointer - I made a pull request to change that in the firmware but it’s not been applied yet. I forgot I had this applied locally.

I’ve republished flashee to work with the existing non-const pointer. Only flashee-eeprom-impl.h changed - if you copy that to inc/flashee folder it should now compile for you.

Alas, I’m still getting the SOS in the online IDE with this change in place.

1 Like
11

Sorry to dig up an old thread, but I think I finally found the cause of this.

It’s a result of the order that constructors are called on module-scope static instances. The only guarantee is that constructors within the same module are called in the order of declaration, but constructors that depend on other instances in other modules cannot be sure the other instance has in fact been initialized.

The workaround is to put module static instances in an accessor functions, then when the function is called, the constructor is guaranteed to be executed.

I have done this for the static instances in flashee and this fixed the problem.

The crazy thing is that the actual initialization order is based on linker order, and that may vary between builds since it’s based on loosely defined aspects such as the order the filesystem returns the list of files in a directory. This is what makes the problem intermittent.

1 Like