STM32L4: add NUCLEO_L4A6ZG (STM32L4A6ZGTx) target

[61ca52]

Summary of changes

Adds support for the STM32L4A6xG MCU family and the NUCLEO-L4A6ZG development board.

The STM32L4A6 is the cryptographic derivative of the STM32L496, extended only by an AES/HASH hardware accelerator; both parts share the device ID 0x461. The target definition therefore mirrors MCU_STM32L496xG as closely as possible and diverges only where the crypto peripherals require it.

Dependencies
The test results below were obtained with two additional fixes that are submitted as a separate pull request and are not part of this changeset.

1. Heap must not overrun the boot/ISR stack. Without it, tests-mbed-rtos-heap-and-stack fails, because stm32l4_dual_flash_bank.ld grows the heap to the end of SRAM1, leaving no room for the boot stack STM32L4: fix MemManage fault in rtos-heap-and-stack on dual-bank targets #592

2. HSI auto-start-from-Stop consistency across deep sleep, so that the clock tree is restored coherently on wake-up from STOP2 STM32: fix LPUART console hang after first deep sleep (HSI16 off) #591

This PR can be reviewed and merged independently, but the 96/98 figure below is only reproducible on top of that PR. The same holds for the NUCLEO_L496ZG reference run, which was built from the same tree; the comparison between the two therefore remains valid.

Impact of changes

• New target only. No behavioral change to any existing target; the sole edit to shared code is the __FPU_PRESENT redefinition guard in stm32l4a6xx.h, which is a no-op where the macro was not already defined
• Adds DAPLink board ID 0799 to the platform database, making the board auto-detectable by mbed-tools / greentea
• On this target, AES, MD5, SHA-1 and SHA-256 are provided by the hardware accelerator via the *_ALT bindings, CCM and GCM remain software implementations

Migration actions required

None.

Documentation

None required in this repository.

---

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behavior change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[x] Tests / results supplied as part of this PR

Setup
Hardware NUCLEO-L4A6ZG, ST-LINK/V2-1 SN 066FFF535155878281065443, FW V2J47M34, device ID 0x461 rev 2.0. Toolchain GCC_ARM. Host Windows 11, STM32CubeCLT 1.19.0 / CubeProgrammer 2.20.0, SWD 4 MHz under reset. Full Greentea suite.
greentea-log-l4a6.txt

Metric	NUCLEO-L4A6ZG (this PR)	NUCLEO-L496ZG (reference)
Registered tests	119	119
Not run (peripheral / network hardware absent)	21	21
Executed	98	98
Passed	96	96
Failed	2	2
Time	999.80 s	1003.71 s

The reference column is a run of the pre-existing NUCLEO_L496ZG target on the same host, toolchain and ST-LINK firmware, to establish a baseline. The two runs agree in every respect, including the identical sets of skipped tests and of failures.
greentea-log-l496.txt

Passes exercising target-specific code paths:

• tests-mbed-connectivity-mbedtls-multi (4.25 s), -selftest (8.73 s), tests-mbed-device_key-functionality (6.45 s), tests-mbed-storage-kvstore-direct-access-devicekey, tests-mbed-hal-trng validate the *_ALT hardware crypto bindings and the RNG, the one functional area in which this target genuinely differs from the L496
• tests-mbed-rtos-heap-and-stack (14.34 s), tests-mbed-platform-stats-heap, tests-mbed-rtos-malloc, tests-mbed-hal-stack-size-unification split-SRAM heap layout (see Dependencies)
• tests-mbed-drivers-watchdog (6.37 s), -watchdog-reset (13.61 s), tests-mbed-hal-watchdog-reset (11.63 s), -watchdog-timing (28.70 s), including the watchdog-reset-from-deepsleep cases
• tests-mbed-hal-sleep, -sleep-manager, -sleep-manager-racecondition, tests-mbed-drivers-sleep-lock, tests-mbed-hal-lp-ticker, tests-mbed-drivers-lp-{ticker,timer,timeout}, tests-mbed-hal-rtc-reset STOP2 entry/exit and the low-power clock tree
• tests-mbed-usb-device-msd (72.85 s), -serial (30.09 s) USB FS device enumerates and transfers bulk data
• tests-mbed-hal-verify-arduino-pinmap, tests-mbed-hal-pinmap, PeripheralPins.c and the ARDUINO_UNO form-factor declaration

Known failures (2), both pre-existing and host-side:

#	Test	NUCLEO-L4A6ZG	NUCLEO-L496ZG
21	tests-mbed-usb-device-basic	Host test stalls in case 1 (usb control basic test); aborts after 180.90 s, missing __exit event from DUT	Identical: stalls in case 1, aborts after 180.04 s
22	tests-mbed-usb-device-hid	RuntimeError: USB device (SN=3e35156…) not found. after 50 attempts, 5.19 s	Identical: USB device (SN=31778c8…) not found. after 50 attempts, 5.18 s

These are attributed to the Greentea/USB host setup rather than to the target or to Mbed OS:

• both fail identically, same case, same failure mode, same timing to within 1 %, on the already-supported NUCLEO_L496ZG, so the cause predates this PR and is not L4A6-specific
• USB device functionality is demonstrably working on both boards, as usb-device-msd and usb-device-serial pass in the same session immediately afterwards
• both failures are host-side, 21 never receives a reply to the first pyusb control transfer and 22 cannot find the device by serial number at all, consistent with a Windows WinUSB/libusb driver-binding or pyusb backend issue. Not root-caused further.

Not verified: OSPI/QSPI, Ethernet, NFC and filesystem-on-external-flash, not populated on the NUCLEO-L4A6ZG, reported as skipped by ctest identically on both boards.

---

[multiplemonomials]

Nice work on this! Thanks for the contribution and for your careful testing, I appreciate it.

And yeah, the USB tests have had known failures on STM32 for some time, I do not know how to fix it because I don't know much about USB.

[multiplemonomials]

Really minor but next time, if possible, can you push additional commits to the branch when you make changes rather than amending your existing commit? Amending makes it a lot harder to see what changed between your previous version and now. We have PR squashing enabled, so all commits in the PR will get squashed together when merged.

[multiplemonomials]

Thanks for your work on this!