Summary

This pull request fixes mboot boot failures on NUCLEO-N657X0-Q boards with Rev B silicon. The STM32N657X0 chip has two silicon revisions that require different FSBL signing header versions:

• Rev code Z (Cut 1.1) requires STM32_N6_HEADER_VERSION = 2.1
• Rev code B (Cut 2.0) requires STM32_N6_HEADER_VERSION = 2.3

Currently mpconfigboard.mk defaults to 2.1, causing Rev B boards to fail booting after deploy-trusted. The signing header version is updated to 2.3 in this PR.

Additionally, STM32CubeProgrammer v2.21.0 and later no longer auto-align the binary payload to a 0x400-byte boundary. The --align flag has been added to the STM32_SigningTool_CLI invocation in both stm32/Makefile and stm32/mboot/Makefile; otherwise, the signing step fails with an alignment error and firmware-trusted.bin will not be generated correctly.

The board documentation (board.md) has been extended to cover:

• How to select the correct header version for each silicon revision.
• The --align requirement for STM32CubeProgrammer v2.21.0+.
• An alternative ST-LINK flashing procedure for cases where the mboot USB DFU device does not enumerate on the host PC.

Testing

Hardware tested:

• NUCLEO-N657X0-Q board with Rev B silicon (chip marking "B")

Test steps:

1. Build mboot with updated configuration:

   make -C ports/stm32/mboot BOARD=NUCLEO_N657X0

2. Deploy trusted image via ST-LINK (bypassing DFU):

STM32_Programmer_CLI -c port=SWD mode=HOTPLUG ap=1 \
  -el /opt/STM32CubeProgrammer/bin/ExternalLoader/MX25UM51245G_STM32N6570-NUCLEO.stldr \
  -w ports/stm32/mboot/build-NUCLEO_N657X0/firmware-trusted.bin 0x70000000 \
  -w ports/stm32/build-NUCLEO_N657X0/firmware.bin 0x70080000 \
  -hardRst

3. Verify mboot activates:

• Set CN9 to 3-4, JP2 to 1-2.
• Connect USB cable to CN8.
• Red LED2 should blink at 1 Hz, indicating mboot is active.
• Host PC should detect a DFU device.

4. Verify the --align fix:
   Without --align the signing step fails with an alignment error; with the flag added, firmware-trusted.bin is generated correctly.

Documentation:

• Verified that board.md renders correctly and all added information is accurate.

Trade-offs and Alternatives

Defaulting to header version 2.3 means Rev Z (Cut 1.1) users must manually override with STM32_N6_HEADER_VERSION=2.1.However, Rev Z boards are no longer manufactured; all currently shipping boards use Rev B, so this change matches real-world hardware.

Alternatives considered:

1.Runtime header version detection:
The chip revision cannot be easily read before the FSBL is loaded, so build‑time selection is the only practical approach.

2.Using the USB DFU method only:
The DFU method relies on mboot being active, which fails on Rev B without the correct header version. The documented ST‑LINK alternative provides a fallback that works regardless of the mboot DFU state.

Generative AI

I used generative AI tools when creating this PR, but a human has checked the
code and is responsible for the code and the description above.