zephyr-cp/_bleio: don't let an unsupported Tx power command block advertising

[mikeysklar]

What

start_advertising() on zephyr-cp could not advertise at all on a controller that does not implement Zephyr's vendor-specific Tx power command. It now treats the Tx power write as best-effort and advertises anyway. An explicit adapter.tx_power = n still raises on failure.

Why

common_hal_bleio_adapter_start_advertising() calls set_tx_power() unconditionally before bt_le_adv_start(). That sends BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL (0xfc0e), a Zephyr vendor-specific HCI command rather than a Bluetooth spec one. A controller without Zephyr's VS extensions rejects it, the call returns -EIO, and start_advertising() raised before it ever reached bt_le_adv_start().

On a SiWx917-DK2605A (Zephyr board siwx917_dk2605a), whose controller has its own vendor command at 0xfc06 for RF power:

<wrn> bt_hci_core: opcode 0xfc0e status 0x01   (Unknown HCI Command)
OSError: [Errno 5] Input/output error

This affects any controller lacking Zephyr's VS HCI commands, not only that one. The shared-bindings default is tx_power=0, so every adafruit_ble program hits this path on every start_advertising().

The fix splits the command into a non-raising _try_set_tx_power(). common_hal_bleio_adapter_set_tx_power() still raises, so a deliberate Tx power assignment fails loudly. start_advertising() calls the non-raising form and continues at the controller default. There is no log line on rejection because it would print on every start_advertising() on such a controller.

Hardware tested

• SiWx917-DK2605A, SoC SiWG917M111MGTBA, zephyr-cp. Before: OSError: [Errno 5] from start_advertising(), zero scanner hits. After: the board advertises and is discoverable by name from an external BLE scanner. That test was done at the end of July on the SiWx917 bring-up tree; the change has been rebased onto current main and recompiled, not re-run on hardware today.
• adafruit_feather_nrf52840_zephyr: build only, on current main with this change. Not run on an nRF52840.

Not tested: a controller that implements the VS command. The only behaviour change for those is that a failure of the command no longer aborts advertising.

Scope

This is older work from the SiWx917 bring-up. An LLM review pass over the zephyr-cp _bleio work in progress flagged it as relevant to the BLE workflow effort, so it is being filed now on its own rather than waiting for the SiWx917 board PR (#11218). It does not depend on that PR.

AI assistance

Written with Claude Code. I verified the failure and the fix on the DK2605A myself, reviewed the diff by hand, and confirmed the rebased change compiles for adafruit_feather_nrf52840_zephyr on current main.

[mikeysklar]

Closing, this is already in #11226 as bleio_adapter_set_tx_power_noraise(). Same fix, same reason. For what it is worth, the VS command rejection (opcode 0xfc0e, status 0x01) and advertising working once it is best-effort are both confirmed on a SiWx917-DK2605A, so that part of #11226 holds on a non-Nordic controller.