[STM32H7 / CubeMX] Black screen + startup HardFault: CubeH7 1.13.0 linker template splits .data/.bss across DTCM and AXI SRAM

[233lzx]

> Keywords (for search): STM32H7, H743, HardFault, black screen, startup crash, linker script, .ld, TLS, .tdata, .tbss, CubeMX, X-CUBE-AI, CubeIDE, GCC, arm-none-eabi

## Symptom (check if this matches you)

- Power-on: LCD **backlight on but screen stays black**; firmware seems to never start.
- Debugger stops in `HardFault_Handler`; `CFSR = 0x400` (**IMPRECISERR**, imprecise bus error).
- Backtrace stops in `Reset_Handler` (startup), **before `main()`**.
- Often appears **right after regenerating with CubeMX** (e.g. after adding X-CUBE-AI).

## How I traced it

1. `CFSR = 0x400` → imprecise bus error = a write to an invalid address.
2. `bt` → crashes in the startup `.bss` zero-fill loop (`str r3, [r2]`).
3. Build map shows the four startup symbols are **not in the same memory region**:
```
_sdata = 0x24000000   (RAM / AXI SRAM)
_edata = 0x20000000   (DTCM - BELOW _sdata!)
_sbss  = 0x20000000   (DTCM)
_ebss  = 0x240002FC   (RAM / AXI SRAM)
```
→ the `.bss` zero-fill walks from DTCM (0x20000000) up to AXI SRAM, **crossing the
unmapped gap 0x20020000..0x23FFFFFF** → bus error → HardFault → black screen.

## Root cause

**The STM32CubeH7 firmware package 1.13.0 linker template** (applied by CubeMX)
generates `STM32H743xx_FLASH.ld` with **TLS sections (`.tdata`/`.tbss`)** and
defines `_edata` / `_sbss` **inside those TLS sections** instead of inside
`.data` / `.bss`.

- On H7: `.data/.bss` are placed in **AXI SRAM (0x24000000)**, while `.tdata/.tbss`
  are placed in **DTCM (0x20000000)** → the symbols span two **non-contiguous**
  memory regions → crash at startup.
- **NOT caused by X-CUBE-AI**: non-AI projects (STM32F103, STM32G431) have the same
  TLS sections in their `.ld`.
- **NOT caused by the CubeMX version**: the `.ld` template content comes from the
  firmware pack; CubeMX just applies it.
- **Single-RAM MCUs (F1/F4/G0/G4) are unaffected** (all sections land in one RAM);
  only multi-RAM parts like STM32H7 crash.

## Quick check (30 seconds)

```powershell
# 1. Does the .ld contain injected TLS sections?
Select-String -Path "STM32H743xx_FLASH.ld" -Pattern "\.tdata|\.tbss"

# 2. Are the 4 symbols in the same region?
Select-String -Path "build/Debug/*.map" -Pattern "_sdata =|_edata =|_sbss =|_ebss ="
```
If you see `.tdata/.tbss`, or the four symbols span different regions → that's it.

## Workaround (verified working)

Remove the injected TLS sections and put `.data`/`.bss` in one region (DTCMRAM
here; RAM works too, as long as it is a single region):

```ld
.data :
{
  . = ALIGN(4);
  _sdata = .;
  *(.data) *(.data*) *(.RamFunc) *(.RamFunc*)
  . = ALIGN(4);
  _edata = .;
} >DTCMRAM AT> FLASH

.bss :
{
  _sbss = .;
  __bss_start__ = _sbss;
  *(.bss) *(.bss*) *(COMMON)
  . = ALIGN(4);
  _ebss = .;
  __bss_end__ = _ebss;
} >DTCMRAM
```

After the fix the map shows all four symbols inside DTCM and the firmware boots.

## Attachment

`ST_bug_repro.zip` (see report folder) contains:
- Broken and fixed `.ld`
- Broken and fixed `.map`
- Two full buildable projects: `h7` (broken) and `h743` (fixed)
- Formal report `ST_BUG_REPORT.md`

## TL;DR for anyone hitting this

> If your H7 was regenerated with CubeMX (CubeH7 1.13.0) and suddenly shows a black
> screen / startup HardFault, **check your `.ld` for `.tdata/.tbss` first** — it is
> almost certainly this linker template issue, not your code. Delete the TLS
> sections and keep `.data/.bss` in one region.
 

See the attachment for details.