# Musca-B1

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

The
[Arm Musca-B1](https://developer.arm.com/Tools%20and%20Software/Musca-B1%20Test%20Chip%20Board)
test chip board is automated for Trusted Firmware-M (TF-M) testing. It is a
Cortex-M33 board with an on-board DAPLink; power, flashing (over USB mass
storage) and the serial console all run over the single DAPLink USB
connection, so no board modification is required.

This document applies to the following boards:

* Musca-B1: musca-b

## Components

The following components are required to automate the board:

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

## Board modifications

None. The board is flashed by copying the image onto the DAPLink USB mass
storage, so there is no boot-mode switch to change and no flying leads to
solder.

## Connections

Connect the board's DAPLink USB connector to **USB port 3** on the LAA
(`laacli usb 3`). That port powers the board and exposes both the DAPLink
mass-storage flash interface and the DAPLink 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 `musca-flash-fw`, shipped in the LAA overlay
(`appliance/firmwares/musca-b`). baklaweb provisions the overlay into
`/usr/local/` on the dispatcher, and the device dictionary's
`flasher_deploy_commands` calls the wrapper directly: the dispatcher is
already privileged and has USB access. The wrapper (adapted from LAVA's
`to: musca` deploy):

- copies the TF-M image onto the DAPLink USB mass storage, retrying if the
  DAPLink rejects the program, and lets the DAPLink "Auto Reset" run it.

The device dictionary's `hard_reset_command` is a no-op (`true`): the board is
reset in-band by the DAPLink's own "Auto Reset" after each flash, so no separate
reset step is needed.

### No USB power-cycle

The board is powered on once (`laacli usb 3 on`) and **never** power-cycled;
`power_off` is a no-op. The DAPLink "Auto Reset" after each flash resets the
Musca chip but not the DAPLink, so the console stays attached across the reset
and the boot is captured from the first byte, which the USB-power-cycle `musca`
boot method loses. (The Musca DAPLink also used to wedge on a VBUS-only
power-cycle by back-powering through the data lines; the LAA now cuts the data
lines too, so that is no longer a concern.)

## Health check

The health check flashes a TF-M image and waits for `Non-Secure system
starting...` on the console.