# STM32WBA65I-DK1

```{include} common-alert-enablement.md
```

The
[STM32WBA65I-DK1](https://www.st.com/en/evaluation-tools/stm32wba65i-dk1.html)
Discovery kit is automated for Trusted Firmware-M (TF-M) testing. It is a
Cortex-M33 board with an on-board STLINK-V3; power, SWD flashing and the
serial console all run over that single ST-LINK USB connection, so no MIB
and no board modification are required.

This document applies to the following boards:

* STM32WBA65I-DK1: stm32wba65i-dk1

## Components

The following components are required to automate the board:

- One USB cable from an LAA USB port to the board's on-board STLINK-V3
  connector. This single link carries power, SWD flashing and the UART
  console.

## Board modifications

None. The board is flashed over SWD through the on-board ST-LINK, so there
is no boot-mode switch to change and no flying leads to solder.

## Connections

Connect the board's STLINK-V3 USB connector to **USB port 2** on the LAA
(`laacli usb 2`). That port powers the board and exposes both the SWD debug
interface (used for flashing and reset) and the ST-LINK Virtual COM Port
(the DUT console).

The console enumerates on the LAA as `/dev/ttyACM0` at 115200 8N1 and is
served over telnet on port **2020**.

## Software

Flashing is done by `stm32wba65i-flash-fw`, shipped in the LAA overlay
(`appliance/firmwares/stm32wba65i-dk1`) alongside a Segger-stripped
STM32CubeProgrammer tarball. baklaweb provisions the overlay into
`/usr/local/` on the dispatcher, and the device dictionary's
`flasher_deploy_commands` calls the wrapper directly, with no container: the
dispatcher is already privileged and has USB access. The wrapper (adapted
from `lab-scripts/stm32_tfm_flasher.sh`):

- extracts the bundled CubeProgrammer into a cache directory on first use,
- unpacks the TF-M build tarball and runs its `TFM_UPDATE.sh` to flash the
  secure and insecure images over SWD, and
- resets the board with `STM32_Programmer_CLI -c port=SWD mode=HOTPLUG -rst`
  (a software system reset). This DK's NRST is **not** wired to the ST-LINK,
  so a hardware reset (`HWrst`) does not re-run the firmware; and a USB
  power-cycle re-enumerates the ST-LINK VCP and drops the first seconds of
  boot output the test monitor needs. The software reset re-runs the firmware
  while keeping the console up.

### STM32CubeProgrammer licensing

STM32CubeProgrammer is proprietary. Its licence (SLA0048) permits
redistributing STMicroelectronics own components ("or any part thereof"),
so the bundled `inputs/stm32cubeprogrammer-2.23.0-arm64-stlink.tar.gz` is a
**Segger-stripped** arm64 build: `libjlinkarm.so`, `99-jlink.rules` and
`License_Segger_JLink.txt` are removed, because the SEGGER J-Link licence
forbids redistribution and we flash over ST-LINK, not J-Link.
`STM32_Programmer_CLI` does not link `libjlinkarm.so` (it is only
`dlopen`'d for J-Link probes), so dropping it has no effect on ST-LINK
flashing. `LICENSE-SLA0048.txt`, `Additional_Licence_Terms_STM32CubeProg.html`
and `DISCLAIMER` are kept next to the binaries to carry the required notices.

## Health check

The health check flashes a small "hello world" TF-M image and waits for
`Hello DK WBA6 is OK` on the console.