CubeProgrammer v2.23.0: STM32H757 dual-core option bytes (BOOT_CM4_ADD0/1, BCM4/BCM7) "do not exist", and raw writes to FLASH_BOOTx_PRG hang
Setup: STM32H757 (device ID 0x450, rev V), ST-LINK/V2 firmware V2J48S7 over SWD, STM32CubeProgrammer v2.23.0 CLI on Windows 11.
Problem 1: the CM4 boot address can't be set.
STM32_Programmer_CLI -c port=SWD mode=UR -ob BOOT_CM4_ADD0=0x080E BOOT_CM4_ADD1=0x080E
prints "Warning: Option Byte: boot_cm4_add0, does not exist" (and the same for add1), and exits with code 0, so scripts don't notice. "-ob displ" shows only the single-core BOOT_ADD0/BOOT_ADD1, with no BCM4/BCM7. The silicon is dual-core: FLASH_BOOT4_CUR (0x52002048) reads correctly, and BCM4/BCM7 are set in FLASH_OPTSR_CUR.
Cause, as far as I can tell: in Data_Base/STM32_Prog_DB_0x450.xml the H757 matches configuration 0 ("Security extension available && multi-core"). In v2.23.0, every dual-core field leaves out config 0, while the single-core BOOT_ADD0/1 does include it:
BCM4 (FOPTSR_CUR): config "1"
BCM7 (FOPTSR_CUR): config "1,4,5"
BCM4, BCM7 (FOPTSR_PRG): config "1,4,5"
BOOT_CM4_ADD0/1 (FBOOT4_CUR and _PRG): config "1,4,5"
BOOT_CM7_ADD0/1 (FBOOT7_PRG): config "1,4,5"
BOOT_ADD0/1, single-core (FBOOT7_CUR and _PRG): config "0,2,3,6,7"
The database in the CubeIDE plugin cubeprogrammer 2.2.400 (February 2026) has config 0 on all of the dual-core fields ("0,1" or "0,1,4,5"). Plugins 2.2.200 (July 2025) and 2.2.300 (November 2025) match 2.2.400 for BOOT_CM4_ADD0; plugin 2.2.500 (June 2026) matches v2.23.0. v2.23.0 also contradicts itself: BCM4 in FOPTSR_CUR is config 1 only, while BCM7 next to it has "1,4,5".
Problem 2: raw writes to the boot address registers hang. After unlocking with FLASH_OPTKEYR (those two writes complete), a "-w32 0x5200204C <value> -nv" (FLASH_BOOT4_PRG) or "-w32 0x52002044 <value> -nv" (FLASH_BOOT7_PRG) never returns: "Downloading..." stays on screen. Killing the CLI then left the ST-LINK in DEV_USB_COMM_ERR until the USB device was restarted.
Impact: on the H755/H757, current tools can't write or display the CM4/CM7 boot addresses or the core boot enables, and production scripts don't notice. A new part then keeps the factory CM4 boot address 0x08100000. On a design that uses bank 2 as a firmware update slot, the M4 then boots whatever image lands there.
Workaround: the same register sequence works through ST-LINK_gdbserver and arm-none-eabi-gdb with plain memory writes: FLASH_OPTKEYR 0x08192A3B then 0x4C5D6E7F, the new value to FLASH_BOOT4_PRG, OPTSTART in FLASH_OPTCR, wait about 2 s, set OPTLOCK. Don't read the FLASH registers while the commit runs: the bus stalls and gdb reports "Cannot access memory". FLASH_BOOT4_CUR shows the new value afterwards. The CLI from the CubeIDE cubeprogrammer 2.2.400 plugin also still accepts BOOT_CM4_ADD0/1.
Request: please restore config 0 on the dual-core fields listed above, and look at why a -w32 to FLASH_BOOTx_PRG hangs instead of writing or failing. It would also help if an unknown option byte name made the CLI return a non-zero exit code.