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]

I'm not familiar with Keil. I use the linker script file .ld to specify zero heap. What I am asking is: do you intend to have zero use of the heap and specify that somewhere? I don't think the compiler knows that you have allocated zero heap (in the linker script), and will generate code to use the heap. AFAIK, static doesn't mean you can only have one instance, it means "not on the heap".

[Jonathan]

I've tripled check, static in a class means "one global instance, regardless of how many objects you allocate". "ld" is the GNU linker, as far as I know I'm using armlink. Technically I haven't allocated 0 heap, I've got some heap, I'm trying to get a lot more, but my goal isn't either to use heap. I'm just trying to solve my crash. I gave it a lot of thoughts over the weekend and realized it may also be a stack overflow issue.

[butch]

I suggest you use debugger to understand the crash. Assume the 'crash' is infinite loop in the default hardfault handler. Pause the program and examine the registers to see whether the stack pointer is invalid. Or some other general purpose register (as a pointer into the heap) is invalid. Where invalid means: out of range of real memory addresses. You might need a basic understanding of assembly language and the ARM architecture. I think there are two sets of registers (for the main context and the interrupt/handler context) and you might need to examine the main context, i.e. where your app was when the hardfault occurred.