Running out of memory?

[Jonathan]

I'm writing a firmware, with SD130, using mbed libraries.

Firmware used to run fine. I added a new object, and now, when connecting, it hardfaults. I put a breakpoint in the connection callback, this breakpoint is never reached.

The object I added is a RamStorageManager.

Here's a code excerpt:

class RamStorageManager : public StorageManager
{
protected:
  static const uint32_t UserEntries = 2;
  static const uint32_t EventEntries = 2;
// Begin
  Otp OTP;
  Information Information;

  Event events[EventEntries];
  User users[UserEntries];
// End

//...
}

Now, if I comment the code between "begin" and "end", everything works fine. Note, the object is a global variable, statically allocated:

RamStorageManager storageManager;

It is actually currently unused (a reference to is is passed to another object, which stores it and doesn't use it). The object doesn't have code anymore (all methods are just "return false", but they are anyway never called).

As far as I know, my object should be stored in global memory, at an offset statically allocated at compile time. It should not affect the heap.

So my wonder is: why do I get a hardfault when my object gets bigger?!

[butch]

Maybe you need "static" on the data members of the class e.g "static Otp OTP". That is, maybe the data member instances are on the heap. Also, are you saying that you have no heap allocated in your linker script, so that you will get a hard fault if the compiler generates any code that uses the heap?

[Jonathan]

No I don't want them static (for architecture reasons). Members properties might be on the heap, indeed, though afaik that's not how it works. I do have some heap allocated in my scatter file, but my own code should not allocate anything on the heap, and as far as I understand neither does the SD.

[butch]

What architectural reason? I am not sure about it either, but if the properties are not static, they are accessed through a "this" pointer, and I wonder where and when they are allocated. You did not answer whether you have allocated any heap. What is your hypothesis about when and why the hard fault occurs?

[Jonathan]

Heap is allocated thru the scatter file (using Keil) I don't know of another way to allocate it when not having a arm_startup_nrf51.s . Unless I'm mistaken, "this" will be allocated during compilation. Looking at the map file, the bigger my object is, the bigger my zero-init section is (specifically, the ZI section of my main.o increases with the size of the object). So I would conclude my object is definitely not on the heap.

My hypothesis is not valid and was that maybe the SD would allocate something dynamically and run out of memory. All I know is the issue doesn't happen if my object is smaller.

[Jonathan]

Oh and sorry, not static because I want to be able to use other instances of the object.