Stack and Heap memory Overlap with ARMCC on Nucleo-F401RE

[hasnainvirk]

While debugging an issue ARMmbed/mbed-os-example-client#37
it was noticed that the application went to a hard-fault with ARMCC on Nucleo F401RE when RAM was exhausted. However same behaviour would not cause a hard fault with GCC.

On further inspection of MAP files, it was noticed that:

• With ARMCC , the system was crashing because an overlap between Heap and Stack took place.
  Heap and Stack extend towards each other from opposite directions and there is no check to detect the collision.

[c1728p9]

Hi @hasnainvirk, were you building for ARM or uARM? Also, could you attach the map file?

Heap limits are set in the function set_stack_heap and are enforced for the IAR, ARM and GCC_ARM toolchains. The heap_and_stack test tests that malloc appropriately sets its limits by allocating until malloc returns NULL. I recommend running this test on the NUCLEO-F401RE to confirm this is the problem you are seeing.

Finally, which stack are you seeing overflow? The main stack is located in the zero init region and grows away from the heap. Tasks can also be created with dynamic memory and these would show up as being inside the heap. Finally, the interrupt stack pointer (MSP) is located at the end of RAM and does grow towards the heap.

[hasnainvirk]

@c1728p9 Building for ARM and GCC_ARM. You can recreate this if you use mbed-os-example-client with LOWPAN_ND (mbed-os 5.1.0). I was able to evade the issue if I reduce RAM consumption by telling mbedTLS to make ROM tables instead of RAM (8K saving) and then reducing the mbed-mesh-api heap allocation (nanostack heap) from 32.5 to 30K. I had also attched nanostack sources with the app as the partner had been attaching sources.

[hasnainvirk]

@c1728p9 @yogpan01 @SeppoTakalo @kjbracey-arm I just tried with mbed-os -5.1.3. It seems that the hard fault issue because of RAM overflow is fixed in this patch release.

[c1728p9]

Heap limit checking and the test to verify it aren't in mbed-os 5.1.0. The first version of mbed-os to have this is 5.1.2. This was introduced in the PR #2402. @hasnainvirk can this issue be closed?

[hasnainvirk]

Yes, this can be closed. @c1728p9 However, I checked PR #2402. We had seen the issue of two memory regions in K64F also. And a fix was made in mbed-OS3.
ARMmbed/target-kinetis-k64-gcc@2fcaed5