STM32H7: Fix wrong address for DTCM in linker script

[multiplemonomials]

Summary of changes

I noticed that after #326, compilation is failing for STM32H7 targets! This turns out to be because:

• The STM32H7 linker scripts use NVIC_RAM_VECTOR_ADDRESS to find the start of DTCM
• Most of the cmsis_nvic.h files define NVIC_RAM_VECTOR_ADDRESS based on MBED_RAM_START. This was not really the correct way to do it, as on MCUs with multiple RAM banks, it's hard to know what ram bank MBED_RAM_START actually refers to
• MBED_RAM_START now points to SRAM_D2 rather than DTCM.
• This causes the linker script to try and store the crash data RAM in SRAM_D2 which is already used for the Ethernet stuff (which I actually plan to change soon, but oh well)

To fix this, I updated the cmsis_nvic.h files to remove the no-longer-needed RAM definitions and to define NVIC_RAM_VECTOR_ADDRESS in terms of the correct MBED_RAM_BANK_SRAM_DTC_START constant.

Impact of changes

Compilation fixed for STM32H743, and possibly other MCUs in this family.

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

STM32H743 compiles again!

[wdx04]

I have a application that uses DMA for reading/writing SD cards in FAT filesystem.
It works with the old linker script because it doesn't make use of DTCM.
But the new STM32H7 linker scripts seem to use DTCM aggressively, I can see 99.5% SRAM_DTC usage in the build output.
And my application fails with the new linker script (RX Overrun error), because the FATFilesystem buffer is located in DTCM.

[wdx04]

I have a application that uses DMA for reading/writing SD cards in FAT filesystem. It works with the old linker script because it doesn't make use of DTCM. But the new STM32H7 linker scripts seem to use DTCM aggressively, I can see 99.5% SRAM_DTC usage in the build output. And my application fails with the new linker script (RX Overrun error), because the FATFilesystem buffer is located in DTCM.

Solved by removing the MBED_SPLIT_HEAP macro in my custom_targets.json5：

"macros_remove": ["MBED_SPLIT_HEAP"]

[JojoS62]

I had the same issue, removing split heap fixed it. So removing this macro means that the additional heap_0 is not used as heap?

[multiplemonomials]

Update: this is fixed in master branch now! We disabled DTCM for the heap