Adding additional memory segment crashes if I don't use Fixed-size stack &Heap

[MrZANE]

Hi

In my STM32L432CC project I needed an area in flash where I could add some data the would be detectable (And alterable) by a c# app I’ve written that gets run in the post-build scripts.
I also want this position in flash to be the same even if I change processor to one with small, or bigger, flash so I want to put my section right after the ISR table.
So I turned to the “Additional memories” configuration page and added a PROG_INFO section in Flash at 0x080001A0 with the size of 0x20 and, only, the “Contains initialized data” checked.
I included the ExtraMemories.h file and created a struct that reside in that section.

Now my program started crashing shortly after starting up (HardFault_Handler after a call to _Bfree according to the call stack) and I started investigating.
This is what I found:
1. That data I want to store at that specific location is there like it’s supposed to.
2. If I add the embedded framwork “Fixed-size stack and heap” everything works like it should again.
3. If remove the PROG_INFO_DATA section define from my code everything works again (Of course the data isn’t at the position I want, but it works).

What I can’t understand is why placing a chunk of data in flash would affect the stack and/or heap causing my program to crash.

Any Ideas?

Kind regards

Jimmy

 

 

 

[MrZANE]

After changing to software floating point I got some more info in the callstack:

[support]

Sorry, this looks like a project-specific issue (e.g. stack/heap overflow somewhere in the code), so we can provide limited help on this topic.

Our best advice would be to use the Embedded Memory Explorer to compare the memory layout of the 2 builds (https://visualgdb.com/tutorials/arm/comparebuilds/) and try making something in between to narrow down the problem (e.g. manually fill the same area of the FLASH memory with 0xFFs).

[MrZANE]

What I can’t really understand is why moving a const. array (flash) should change the stack/heap usage (RAM).
If that is the case I fully understand that you can’t help me, but I would be grateful if you could just have a look at my questions and what I’ve found below.

When NOT using fixed heap&stack framework how is the memory for stack & heap calculated and distributed?
Where can I see this in the build outputs?

Is there any tools in VisualGDB to analyze hardfaults, other than reading CFSR register and manually decoding?

This is the calculated call stack usage

 

This is from running the code, stopped on just the printf that will cause a hardfault (btw. iass, the float to be printed, has a value of 0.0489999987)

As I see it there should be plenty of stack left as I don’t use any heap at all (at that time), unless the automatic stack/heap setup is strange in some way.
Or is there something I’m missing?

 

Breaking news:

CFSR = 0x8200 => BFARVALID = 1, PRECISERR = 1
Seems like a busfault trying to access address 0xe747ae94 (From BFAR register)
Now the question is why that happens

[support]

Sorry, this is way too project-specific and is not covered by our regular product support. We can help you understand specific settings of VisualGDB, but we are not able to troubleshoot project-specific issues without charging consulting fees.

[MrZANE]

I understand, no worries.

Would you mind answering the following questions though? Please 🙂

When NOT using fixed heap&stack framework how is the memory for stack & heap calculated and distributed?
Where can I see this in the build outputs?

Is there any tools in VisualGDB to analyze hardfaults, other than reading CFSR register and manually decoding?

[support]

No problem, please find the explanation below:

1. When NOT using fixed heap/stack, VisualGDB projects will use the default gcc/newlib logic for placing stack/heap:
   • The stack begins just before the _estack symbol (typically, end of RAM) and grows downward (i.e. address decreases with each push).
   • The heap begins after the end symbol (per linker script) and grows upward.
   • There are no hard stack/heap size limits. Each time the heap is extended, the heap logic checks whether the new end-of-heap would be beyond the current stack pointer. There is no check for stack pointer overrunning into the heap later.
2. When using fixed stack/heap, VisualGDB does the following:
   • It adds the ReservedForStack and FixedSizeHeap symbols into the built executable (see the StackAndHeap.c file).
   • The heap is located inside the FixedSizeHeap variable and will never grow beyond it.
   • The stack is still located _estack (growing downwards). It gets to use the space allocated for ReservedForStack and all the space after it (before the end of RAM). The ReservedForStack variable ensures that you get a link-time error if there is not enough space to place the requested stack size.

You can see this by reviewing the .map file produced by VisualGDB (use the VisualGDB Project Properties or VS Project Properties -> Linker to enable map files) or by using the Embedded Memory Explorer.

Currently, VisualGDB does not offer any special tools for analyzing hardfaults, sorry.

[MrZANE]

Thanks for the info about the stack.

Hopefully I will sort out the rest myself.

 

Kind regards

Jimmy

[Author]

Posts