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]

Could that be a stack overflow? Local variable = placed on stack, accessed relative to SP. Stack is decreasing while top of heap (sbrk) is increasing. The INVSTATE bit in the fault may indicate that the stack was overwritten, i.e. an even value was found where a return address (with thumb bit set in LSB) was expected. The fault analyzer can show where the fault happened, and you can jump to that place.

[Tesla DeLorean]

Screens aren't telling me much.

Need to look at the code disassembly and registers where it faults.

The highlighted values don't have word aligned addresses, the CM7 will fault on LDRD/STRD on these.

If you're blowing the scope on the local/auto variables you can easily break the return address on the stack, but the stack trace at least seems to indicate it can follow what's being going on.

Make sure the stack is adequate, place markers, and determine depth/usage

[Amilton Rogério da Silva]

Hello, and thank you very much for the quick response.

  I increased the minimum STACK, it was 0x400 and now it is 0x4000

_Min_Heap_Size = 0xA000;

_Min_Stack_Size = 0x4000;

 But the result is still the same.

 I compiled without using mymalloc, just to show more examples of the overlapping addresses, and under these conditions the contents of several of the global variables are changed.

  I have doubts if it is a STACK problem since the routine works and does not generate a fault depending on what is executed before. To contextualize in the first pass two routines are called, image capture and then another for comparison, this does not generate hardfault. But when I call only the comparison routine, several of the addresses appear overlapping and generate the hardfault in the next passage through GUI_Exec. As I said other variables are changed, but the content is not critical to generate the fault.

  I executed the code step by step in disassembly to the point of the GUI_Exec that generates the fault, luckily occurs in the first instructions. The address in R7 appears to be the variable GUI_pFTimerExec in 0x2000fa98, in operation REV R3, R7. In the next step, jump to the Hardfault (see images)

[Amilton Rogério da Silva]

Hi,

Here are some more screens.

The execution generates the fault in the instruction BLX R4. It is possible to see that R4 has an invalid value for the jump 2883592 = 0x2C0008.

In normal execution, the value of register R4 is 0 and the address jumps to WM_Exec. (_no_fault image)

[Amilton Rogério da Silva]

Hi,

I'm sending it to the screens in the attached file.

[Tesla DeLorean]

Jumping to an EVEN address will definitely fault.

Check you've initialized the structures properly. Use calloc()

[Amilton Rogério da Silva]

"Check you've initialized the structures properly"

I will review the structures, they were not made by me. It is difficult to imagine what kind of errors in a structure could mess with the allocation of the starting address of the heap memory at the entrance of this function.

[TDK]

Does malloc hand out addresses in the heap space? In order for stack variables and heap variables to be in the same location, either you overflowed the stack or malloc is handing out bogus addresses.

[Tesla DeLorean]

Hard to keep track of the multiple issues here.

Your startup.s code will determine what memories are cleared, and those which are not.

The stack should be assumed to contain random junk when using auto/local variables.

Memory allocated from the heap can also contain junk, the SDRAM is likely to get the least attention as you're probably not initializing it in the startup code, nor clearing it.

Different memories can behave differently, latent errors may bite you in different ways.

Hard Faults typically indicate gross errors.