Fix heap allocation on STM32H7Ax family

[wdx04]

Summary of changes

Use AXI SRAM for main memory and AHB SRAM for additional heap on STM32H7Ax family.
Fix wrong IROM1 size on STM32H7A3ZITxQ and STM32H7B3ZITxQ(was 128KB, should be 2MB).

After Split Heap was implemented on STM32H7, any heap allocation on STM32H7Ax family will fail with an "Out of Memory" error. Comparing the linker script of STM32H7Ax_FAMILY and STM32H743_STM32H72x_FAMILIES, I found the former script uses AHB SRAM as main memory and AXI SRAM as additional heap, but the latter one uses AXI SRAM as main memory and AHB SRAM as additional heap. The current Split Heap implementation requires the additional heap to be placed at a higher address than the main memory. Given the fact that AXI SRAM starts at 0x24000000 and AHB SRAM starts at 0x30000000, the current linker script of STM32H7Ax_FAMILY does not meet the requirement and needs to be modified.

Impact of changes

Migration actions required

Documentation

None

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[X] Tests / results supplied as part of this PR

Tested by calling malloc() to allocate 16KB heap memory and check if the pointer address returned by malloc is within the AXI SRAM range(0x24000000-0x240FFFFF).
Tested on NUCLEO-H7A3ZI-Q and a custom board with STM32H7B0VB.

---

[multiplemonomials]

Ah nice catch on this! I guess I missed that AHBSRAM starts at a higher address.

Normally though, we try to place globals (e.g. the .data and .bss sections) in whichever RAM bank is the largest. So, we probably don't want to actually switch AHB SRAM and AXI SRAM unless there's a specific reason that AXI SRAM doesn't work. What we may want to do instead is just switch the .heap and .heap_0 sections. That should get things running again without changing anything else about the memory config.

[wdx04]

Ah nice catch on this! I guess I missed that AHBSRAM starts at a higher address.

Normally though, we try to place globals (e.g. the .data and .bss sections) in whichever RAM bank is the largest. So, we probably don't want to actually switch AHB SRAM and AXI SRAM unless there's a specific reason that AXI SRAM doesn't work. What we may want to do instead is just switch the .heap and .heap_0 sections. That should get things running again without changing anything else about the memory config.

I have tried to switch .heap and .heap_0 sections in the linker script.
But that does not seem to work.

[multiplemonomials]

Wait I was wrong, SRAM_AXI is larger than SRAM_AHB, so it was wrong before, and how you have it now is right!

[multiplemonomials]

Thanks for the fix!