-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Description
The Generic H723VETx board definition appears to use an incorrect RAM size in boards.txt.
Current entry:
GenH7.menu.pnum.GENERIC_H723VETX.upload.maximum_data_size=528384In STM32duino core 2.12.0, this value is passed to the linker as:
-Wl,--defsym=LD_MAX_DATA_SIZE=528384This produces an invalid RAM_D1 / stack layout for STM32H723VETx and causes the application to fault very early after reset.
Observed behavior
The sketch:
- compiles successfully
- uploads successfully
- has a valid vector table at
0x08000000
But after reset:
- the program enters BusFault / HardFault very early
- UART startup output never appears
Root cause
With the current upload.maximum_data_size=528384, the linker places the stack top at:
_estack = 0x24081000This is too high for this target and leads to an invalid RAM_D1 layout.
When overriding the linker symbol to:
LD_MAX_DATA_SIZE=327680the generated memory layout becomes:
RAM_D1 = 0x24000000 / 0x50000
_estack = 0x24050000and the same firmware runs correctly.
Fault evidence
Observed fault registers on hardware:
CFSR = 0x00008600
HFSR = 0x40000000
BFAR = 0x24080FA8
ABFSR = 0x00000308This is consistent with an early bus fault caused by invalid RAM/stack placement.
How to reproduce
Board:
STMicroelectronics:stm32:GenH7pnum=GENERIC_H723VETX- core version:
2.12.0
Compile normally with the generic board definition and flash to STM32H723VETx hardware.
The firmware may compile and upload, but it faults immediately after reset.
Workaround
Override the linker RAM size during build:
--build-property compiler.c.elf.extra_flags='-Wl,--defsym=LD_MAX_DATA_SIZE=327680'After doing this, the firmware runs normally.
Proposed fix
Please change the boards.txt entry for GENERIC_H723VETX from:
GenH7.menu.pnum.GENERIC_H723VETX.upload.maximum_data_size=528384to:
GenH7.menu.pnum.GENERIC_H723VETX.upload.maximum_data_size=327680Additional note
Other H723 entries already use 327680, for example:
WeActMiniH723VGTXGENERIC_H723ZETXGENERIC_H723ZGTX
So this looks like a board-definition metadata inconsistency rather than a general H723 issue.