STM32H7 - SRAM issues - LOCAL VARIABLE ALLOCATED OVER GLOBAL VARIABLE ADDRESS

[Amilton Rogério da Silva]

Hi,

 I am facing an problems that I have never seen before with local variables being allocated at the same addresses of global ones. In the attached image I show an example of a local variable with the address of another variable in the STEmwin library (WM_aCHWinLast). 

The same has already occurred with other global variables, not only with STEmwin. I managed to find some and I was able to solve it by replacing vectors with pointers and allocating their size through customized malloc functions. All STemWin routines work perfectly, only generating the fault in specific executions sequences. The problem seems to be very localized in specific routines, but I don't understand the relationship since the variables are local and should only concern to HEAP memory, which is quite large 0xA000. Other global variables, besides STEwin also appeared with an overlapping address, but these did not generate hardfault.

After going through these routines, with overlapping variables, when executing GUI_Exec () the Hardfault is generated:

Bus, memory management or usage fault (FORCED)

Attempt to switch to invalid state (INVSTATE).

Any ideas or someone already had similar problems?

STM32H750  - Atollic TrueSTUDIO 9.3.0

Thank you in advance.

[KnarfB]

No solution, but few remarks:

• it still smells like overwritten stack, either by a stack overflow or by writing to a local variable out of its array bounds
• increasing _Min_Stack_Size and _Min_Heap_Size is a good idea, but it does not increase or change something at runtime. It only assures (during linking) that sizeof(all global variables) + _Min_Stack_Size + _Min_Heap_Size fits into RAM.
• in one screen dump above (re_arrange_point) there are arrays defined as local variables. Try to make them all static to reduce stack "breathing". Unless you have recursive function calls or multi-threading, I would allocate as much as possible as static (global) data. This also prevents heap fragmentation.
• gcc has a nice options -fstack-usage & -Wstack-usage= to warn about functions with excessive stack usage (at compile time), see https://interrupt.memfault.com/blog/best-and-worst-gcc-clang-compiler-flags. This may help to find memory hogs.

[Amilton Rogério da Silva]

Thanks for the tip.

  I will try to use the native malloc to see the effect. I used a customized malloc that, at first, seemed to have resolved since address overrides did not appear in this function, but this "mymalloc" uses SRAM_D1 and not the DTCM that is the source of HEAP. The algorithm was more stable, but returned to generate hardfault when trying to access the functions in different sequences as I mentioned.

[Amilton Rogério da Silva]

Thanks for the tips, I'll check.

I started looking for overflow that are the most common error for this type of hardfault and it was running step by step, and checking the limits I noticed the tag with the name of a global variable, which in this case was used by the STEmwin library, USB among others. I did the test declaring the vectors as static that even seemed to partially solve the problem but unfortunately I can't give up memory, the structures have vectors with significant sizes, the project does image manipulation and I still have to enable lwip and some more buffers for UART, CAN, TCP communication.

 But it's a good tip, test them as global, so I don't have to pass the strange structures as an argument in these functions and see what happens.

[Amilton Rogério da Silva · Accepted solution]

Solved. Many thanks to all.

  Using the calloc it was possible to see that the function needed more HEAP memory, being necessary to allocate 70kB (0x110000) for the calloc not to return NULL, checking the function I estimated the consumption of 35kB in addition to the previous one with 25kB more. I expected the compiler to indicate a lack of memory in the original version, with a fixed size in the local variables and without any use of malloc or calloc, but the lack of HEAP generated the overflow. Even using mymalloc, the need for HEAP was greater than expected.

I thank you all very much for the tips and attention.