Skip to main content
Hansel
Hansel
Senior
June 10, 2022
Solved

STM32H745: VMA does not match actual memory address for a given variable

  • June 10, 2022
  • 1 reply
  • 1732 views

In my application I am using initialized data in shared memory for the use in a user interface. The memory is in the SRAM2 at 0x30020000. Both cores need to access that same data.

This code is placed in the Common directory so that it is picked up during compile time for both CM4 and for CM7 individually.

When I look at the memory details after compilation, I get the following for CM4:

0693W00000NrdwvQAB.png 

For the CM7, I get:

0693W00000Nrdx0QAB.png 

So in both cases, the address for variable uiDisplayArea is 0x30020960 according to the memory details. Bear in mind that it doesn't matter whether I use optimization -O0 or -O3, the above two snapshots are always the same.

In my code I am using the following statement to prepare dumping the memory address of this variable:

sprintf(strg, "uiDisplayArea pointer: %p.\r\n", uiDisplayArea);

If I compile with no optimization, the result printed is 0x30020960, exactly as expected. However, if I compile with optimization level -03, the CM7 gives me a different address, namely 0x300200b8 (for the CM4 it is still 0x30020960). How can that be?

What I need in the end is that the variable addresses are identical between the two cores, no matter what optimization level I am using. Given the behavior described above, I don't know how to accomplish this.

This topic has been closed for replies.
Best answer by Hansel

Alright, in the meantime I've been able to get my code running. I think the problem I had was related to the fact that there's no control over the order of variables unless they are embedded in a struct. After I've put all the variables of the shared memory in a single struct, the code started behaving properly.

I started to notice different VMA addresses after I changed the optimization mode from -O0 to -Og during debugging. It's still not clear to me though why the reported VMA is different from the actual address when reported during runtime. In any case, it's working now.

1 reply

Hansel
HanselAuthorBest answer
Senior
June 11, 2022

Alright, in the meantime I've been able to get my code running. I think the problem I had was related to the fact that there's no control over the order of variables unless they are embedded in a struct. After I've put all the variables of the shared memory in a single struct, the code started behaving properly.

I started to notice different VMA addresses after I changed the optimization mode from -O0 to -Og during debugging. It's still not clear to me though why the reported VMA is different from the actual address when reported during runtime. In any case, it's working now.

Terms & ConditionsAccessibility statement