0. この記事は？

きっかけ

先日(いつかは覚えてない)から，Arduino IDEの「Select Other Board and Port」ダイアログ内の検索で"N947"のような文字列を入れるとFRDM-MCXN947が候補に上がるようになった．どうやらArduino公式が管理・提供しているパッケージのよう．
気になるので試してみたら，ツールをインポートしてビルドまでは問題なくてきた．しかしボードへの書き込みができない．書き込み手段として設定されているpyOCDはMCXN947に対応しておらず，そこでコケる．
そこで，この春に自前のArduinoサポートパッケージを作った際に，書き込みをNXP公式のLinkServerでできるようにした仕組みをこっちにも入れて試してみた．

問題と原因

Arduino IDE の Zephyr Community Boards (BETA)(パッケージ名 arduino:zephyr_contrib)から FRDM-MCXN947 を使おうとすると，標準のアップロード手段(pyOCD)が

Target type mcxn947vdf not recognized.

で失敗します．これは ArduinoCore-zephyr 側が pyOCD 前提で組まれている一方，Zephyr 本家では FRDM-MCXN947 は pyOCD/OpenOCD をサポートしておらず LinkServer のみサポート，という食い違いが原因です．

この記事は，そのままではアップロードできない状態から，NXP LinkServer 経由でのアップロードを成立させ，実際に Blink スケッチの LED 点滅とシリアル出力までこぎつけた際の手順と，途中で踏んだ落とし穴をまとめたものです．同じ道を通る人が，ここに書いた分だけ遠回りせずに済めば良いなと思います．

検証環境: macOS / Arduino IDE 2.x / arduino:zephyr_contrib 0.56.0 / LinkServer 26.6.137 / FRDM-MCXN947

目次

事前準備: パッケージのインストールとUSB接続
前提知識: ArduinoCore-zephyr の2段階起動モデル
手順1: ローカルパッチでアップロードツールを LinkServer に切り替える
手順2: loader(ブートローダ)を書き込む
落とし穴集
まとめ(チェックリスト)

1. 事前準備: パッケージのインストールとUSB接続

前提: Arduino IDE 2.x は既にインストール済みとします(未インストールの場合は公式サイトから入手してください)．

パッケージのインストール

このまとめは「Zephyr Community Boards (BETA) パッケージは既にインストール済み」という前提で進みます．まだの場合は以下を先に行ってください．

左サイドバーの BOARDS MANAGER アイコン(基板のアイコン)をクリック

検索欄に Zephyr Community Boards (BETA) と入力してインストール
ツールバーのボード/ポート選択ドロップダウンから FRDM-MCXN947 を選択(詳細は4章の画像を参照)

インストールすると ~/Library/Arduino15/packages/arduino/hardware/zephyr_contrib/<バージョン番号>/ が作られます．この記事では執筆時点の最新版である 0.56.0 を例にしていますが，バージョン番号は将来のリリースで変わるので，以降に出てくるパスは手元の環境のバージョン番号に読み替えてください．

USBケーブルは2本，最初から接続しておく

FRDM-MCXN947には物理的に2つのUSBポートがあります．

デバッグプローブ(MCU-Link)用USB: 書き込み・電源供給・loaderの起動ログ用
ターゲットMCU自身のネイティブUSB: ArduinoのSerial(USB CDC ACM)出力用

Serial.printlnの出力を確認したい場合，両方のUSBケーブルをPCに接続しておく必要があります(詳細は5章)．片方だけ接続した状態で作業を始めると，「LEDは点滅するのにシリアルには何も出ない」という分かりにくい症状に遭遇するので，最初から両方繋いでおくのが得策です．

2. 前提知識: ArduinoCore-zephyr の2段階起動モデル

このコアは以下の2段構成になっています．

loader: リセットベクタに常駐する Zephyr ベースのファームウェア．起動後，sketch パーティションを読みに行く．
sketch: LLEXT 形式の再配置可能 ELF として，別パーティション(FRDM-MCXN947 の場合 0x100F0000)に書き込まれる．

つまり「sketch を書き込む(Upload)」と「loader を書き込む(Burn Bootloader)」は完全に別の操作です．以前 west flash などで別のファームウェアを直接書き込んだことがあるボードでは，loader 自体が存在しないため，sketch だけをいくら書き込んでも何も起こりません．

では，何も書き込んだことのない工場出荷状態のボードならどうか? 答えは同じで，やはり loader は存在しません．Arduino公式ブログ(0.56.0リリース記事)にも明記されている通り，ArduinoCore-zephyr でボードを初めて使う際は，新品・使用済みを問わず 必ず一度 Burn Bootloader を実行して loader をインストールする ことが前提の手順になっています．つまり今回踏んだ落とし穴は「以前別のファームウェアが入っていたボード特有の問題」ではなく，FRDM-MCXN947をArduinoCore-zephyrで使う全員が通る初回セットアップの一部です．今回はたまたま「以前のファームウェアが動き続けている」という分かりやすい形で症状に気づけましたが，真っさらな新品ボードの場合は sketch 書き込みが「成功」した(ように見える)まま何も起きず，原因の切り分けがより難しくなる可能性があります．

なぜこの2段階構成なのか

伝統的なArduino実装(AVRのブートローダ方式など)は「アプリ本体を直接焼く」形ですが，Zephyrベースのシステムはドライバ・カーネル・USBスタックなど下回りの部分がかなり大きく，これを毎回スケッチと一緒にリンク・書き込みしていては開発サイクルが遅くなります．そこで，下回りの重い部分(Zephyr本体)を loader として一度だけ書き込み，スケッチ側は LLEXT (Linkable Loadable Extensions，Zephyrの比較的新しい機能) を使って軽量な再配置可能ELFとして動的にロードする形にしています．公式の言葉を借りると

This architecture provides flexibility and faster development cycles.

というのが狙いです．実際，スケッチのアップロードは(loaderを一度書き込んでしまえば)十数KB程度のファイルを1秒足らずで書き込むだけで済みます．フルのZephyrイメージを毎回焼き直すのに比べれば圧倒的に速いです．

もう一つの利点として，loaderはZephyrアプリそのものなので，Zephyrのshellやログ機構をそのまま使えます．スケッチ側に不具合があっても loader 側は無傷のまま残るため，シリアルログでの原因究明がしやすい，という設計上の狙いもあります．

裏を返すと，この2段階構成であるがゆえに，「loaderが入っていないと何も起きない」「loaderとsketchは別々に管理される」という，従来のArduinoに慣れていると見落としやすい落とし穴が生まれているとも言えます．

3. 手順1: ローカルパッチでアップロードツールを LinkServer に切り替える

事前準備: NXP LinkServer のインストール

この方法は NXP LinkServer を使ってアップロードを行います．事前にダウンロード・インストールしておいてください．

👉 Download: https://www.nxp.com/linkserver

OS	インストーラ
macOS	`.pkg` ファイル，ダブルクリックでインストール
Windows	`.exe` インストーラ
Linux	`.deb.bin` ファイル

インストール後は，後述の upload_linkserver.sh が /Applications/ 配下(macOSの場合)を自動検出するため，パスを手動設定する必要はありません．

ローカルパッチ本体は書き換えず，同じディレクトリに *.local.txt を追加することで安全に上書きします(Boards Manager の更新で消えない)．

対象ディレクトリ:

~/Library/Arduino15/packages/arduino/hardware/zephyr_contrib/0.56.0/

GitHubに用意したファイルを使う場合

3ファイルを手で作らなくても，あらかじめ用意したリポジトリからコピーするだけで済みます．

👉 リポジトリ: https://github.com/teddokano/frdm-mcxn947-linkserver-patch

git clone https://github.com/teddokano/frdm-mcxn947-linkserver-patch.git
cd frdm-mcxn947-linkserver-patch

cp boards.local.txt platform.local.txt \
   ~/Library/Arduino15/packages/arduino/hardware/zephyr_contrib/0.56.0/

mkdir -p ~/Library/Arduino15/packages/arduino/hardware/zephyr_contrib/0.56.0/tools
cp tools/upload_linkserver.sh \
   ~/Library/Arduino15/packages/arduino/hardware/zephyr_contrib/0.56.0/tools/
chmod +x ~/Library/Arduino15/packages/arduino/hardware/zephyr_contrib/0.56.0/tools/upload_linkserver.sh

git clone の代わりに，GitHub上の Code > Download ZIP から取得して展開したものを cp してもかまいません．手打ちや複数行の貼り付けによるコマンド混入(落とし穴集を参照)を避けられるので，こちらの方法をお勧めします．

コピーしたら，次のBurn Bootloaderの手順(4章)に進んでかまいません．以下は各ファイルの中身と，その意味を説明したものです．他のボードに応用する場合や，内容を理解したい場合は読んでください．

boards.local.txt

frdm_mcxn947.upload.tool=linkserver
frdm_mcxn947.upload.tool.default=linkserver
frdm_mcxn947.bootloader.tool=linkserver
frdm_mcxn947.bootloader.tool.default=linkserver

注意: upload.tool だけでは不十分です．実際のアップロード動作は upload.tool.default を参照するため，こちらも上書きしないと pyOCD が呼ばれ続けます(詳細は5章)．bootloader.tool も同様に .default の対があり，パッケージのバージョンによっては上流の初期値が pyocd のままのことがあるため，両方明示しておくのが安全です．

platform.local.txt

tools.linkserver.path=
tools.linkserver.cmd=
tools.linkserver.upload.params.verbose=
tools.linkserver.upload.params.quiet=
tools.linkserver.upload.pattern={runtime.platform.path}/tools/upload_linkserver.sh "{build.path}/{build.project_name}.{upload.extension}" {upload.address}

tools.linkserver.bootloader.params.verbose=
tools.linkserver.bootloader.params.quiet=
tools.linkserver.bootloader.pattern={runtime.platform.path}/tools/upload_linkserver.sh "{runtime.platform.path}/firmwares/{bootloader.file}"

tools.linkserver.erase.pattern=

{upload.address} を渡しているのがポイントです．LinkServer は bin ファイル(拡張子 elf-zsk.bin)にはロードアドレスの埋め込みが無いため，FILE:ADDRESS 形式で明示する必要があります．

tools/upload_linkserver.sh

#!/bin/sh
ELF="$1"
ADDR="$2"

LINKSERVER=""
if [ "$(uname)" = "Darwin" ]; then
    LINKSERVER_DIR=$(ls /Applications/ | grep "^LinkServer" | sort -V | tail -1)
    if [ -n "$LINKSERVER_DIR" ]; then
        LINKSERVER="/Applications/$LINKSERVER_DIR/LinkServer"
    fi
fi

if [ -z "$LINKSERVER" ] || [ ! -f "$LINKSERVER" ]; then
    echo "ERROR: LinkServer not found."
    exit 1
fi

echo "Using: $LINKSERVER"

if [ -n "$ADDR" ]; then
    "$LINKSERVER" flash MCXN947:FRDM-MCXN947 load "$ELF:$ADDR"
else
    "$LINKSERVER" flash MCXN947:FRDM-MCXN947 load "$ELF"
fi

実行権限を付与しておきます．

chmod +x .../tools/upload_linkserver.sh

デバイス識別子 MCXN947:FRDM-MCXN947 は LinkServer devices コマンドの一覧から確認したものです．ボードが違う場合はここを変更してください．

Windows/Linuxでは追加対応が必要

ここまでの platform.local.txt の tools.linkserver.upload.pattern はOSサフィックス無し(全OS共通)の1行しか定義していません．Windowsでは .sh をそのまま実行できないため，このままではアップロードが失敗します．また tools/upload_linkserver.sh 内のLinkServer検出ロジックも uname が Darwin の場合しか見ておらず，スクリプト自体はLinuxでも実行できるものの，このままではLinuxでも検出に失敗します．

mcx-arduino-core (後述)に含まれる platform.txt では，OSごとに実行するスクリプトを分ける仕組みを使っています．

tools.linkserver.upload.pattern={runtime.platform.path}/tools/upload.sh "..."
tools.linkserver.upload.pattern.windows={runtime.platform.path}/tools/upload.bat "..."

Windows対応するには次の2点が必要です．

upload_linkserver.sh と同じロジックの upload_linkserver.bat(または .ps1)を用意する．LinkServer本体の検出パスもWindowsでは /Applications/ ではなく C:\Program Files\LinkServer_x.x.x\ あたりを探す形になる
platform.local.txt に tools.linkserver.upload.pattern.windows=... を追加してそちらを参照させる

Windows/Linux対応は今後の課題です． この記事の検証はmacOSのみで行っていますが，将来的にはWindows/Linux環境でも動作するよう対応する予定です．参考として，mcx-arduino-core のMCXA153向けWindows用アップロードスクリプト(upload.bat)が下記リポジトリにあるので，対応方法のヒントとして参照してください．

👉 https://github.com/teddokano/mcx-arduino-core/tree/main/hardware/nxp/mcx

追記(2026-08-02): Windows/Linux対応をPRとして提出しました

上記の課題について，arduino/ArduinoCore-zephyr 本体にPRを出しました．

👉 https://github.com/arduino/ArduinoCore-zephyr/pull/567

ローカルパッチとの主な違いは次の点です．

upload_linkserver.sh に uname によるLinux分岐(/usr/local/LinkServer/ および /usr/local/LinkServer_* を探索)を追加してLinuxに対応，さらに upload_linkserver.bat を新規に用意して platform.txt 側で tools.linkserver.upload.pattern.windows をOS別に定義することでWindowsにも対応．結果として macOS・Linux は共通の .sh を，Windowsのみ .bat を使う形になった
単純にpyOCDをLinkServerへ置き換えるのではなく，mcxn947_autoという新しいツール定義を追加し，LinkServerがインストールされていればそちらを優先，見つからなければ従来通りpyOCDにフォールバックするようにした(LinkServerを入れていないユーザーの挙動は変えない)
boards.local.txt/platform.local.txtによるローカルパッチ無しでも動くよう，upload.address等の値をboards.txt側に直接追加(この3値は本来extra/build.shが生成するboards.local.txt側の値だが，リリースパッケージ化の際にboards.txtへ焼き込まれる値と同じであることを確認した上で追加)

macOS・Windows・Linuxの3環境それぞれで実機(FRDM-MCXN947)への書き込みまで確認済みです．マージされれば，このローカルパッチ自体が不要になります．

4. 手順2: loader(ブートローダ)を書き込む

FRDM-MCXN947が接続されただけの状態では，Arduino IDEはこれがどのようなターゲットであるかをまだ認識できていません．

これを設定するのが，ツールバー左上のボード/ポート選択ドロップダウンです．ここをクリックすると，接続されているポートの一覧(/dev/cu.usbmodemXXXXXXXXのような名前)は出てきますが，ボードはArduino UNO Qのような無関係なものが選ばれたままになっていることがあります．一覧の中にFRDM-MCXN947そのものは出てこないため，このままではボードを正しく指定できません．

一覧の一番下にある Select other board and port... を選んでください．開いたダイアログの BOARDS 欄に n947 のように検索語を入力すると NXP FRDM MCXN947 が絞り込まれるので選択し，右側の PORTS 欄からFRDM-MCXN947(MCU-Linkデバッグプローブ)が使っているポートを選んで OK を押します．どのポートがそれに当たるか分からない場合は，ケーブルを一度抜き差しして増減するポートを確認するのが確実です．

ボードとポートを選び終えると，ようやくArduino IDEがFRDM-MCXN947を書き込み先として認識した状態になります．

Burn Bootloaderの実行

loaderの書き込みは Tools > Burn Bootloader から行います．手順は次の2つです．

(1) Tools > Programmer を開き，ARM CMSIS-DAP compatible を選択します．

(2) Tools メニュー内の Programmer: "ARM CMSIS-DAP compatible" の表示が変わっていることを確認し，その下の Burn Bootloader を実行します．

これでloaderの書き込みは完了です．

`Missing programmer` で止まる場合

Programmerを選択せずに Burn Bootloader を実行すると，以下のエラーで止まります．

Missing programmer

これは ArduinoCore-zephyr の README に記載されている既知の制限で，Tools > Programmer メニューで何かしら選択されていないと Burn Bootloader 自体が実行されない，という Arduino IDE 側の仕様です(選択したプログラマの中身は実際には使われません)．上記の手順どおり ARM CMSIS-DAP Compatible などを選択してから再実行してください．

sketchをアップロードしてLED点滅を確認する

loaderの書き込みが終わったら，通常のBlinkスケッチをアップロードしてLEDが点滅するか確認します．sketch を書き込んでも LED が点滅しない場合，まず疑うべきは loader が未書き込みのままになっていることです(上記の手順を再確認してください)．

次のようなsketchを実行するとLED点滅とシリアル出力の両方を確認できます．

//#define LED LED_BUILTIN
#define LED LED_BUILTIN
#define WAIT 100

void setup() {
  Serial.begin(115200);
  while (!Serial)
    ;

  pinMode(LED, OUTPUT);
}

int count = 0;

void loop() {
  Serial.println("Hello, world!");
  Serial.println("OK");
  digitalWrite(LED, HIGH);
  delay(WAIT);
  digitalWrite(LED, LOW);
  delay(WAIT);

  Serial.println(count);
  count++;
}

このサンプルではsetup()関数内の while (!Serial); によりホスト側のシリアルポートがオープンするまで待つようになっています．
このためシリアルモニタを開くまで setup() の先(pinMode や loop())に進まないため，LEDの点滅も始まりません．

5. 落とし穴集

作業中に実際にハマった点を，そのまま列挙します．

upload.tool と upload.tool.default は別物: boards.txt には両方の定義があり，IDE の通常アップロードで参照されるのは upload.tool.default 側．前者だけ上書きしても pyOCD が呼ばれ続ける．
bin ファイルにはロードアドレス指定が必須: FILE:ADDRESS 形式で渡さないと you must specify a load address via --addr で失敗する．
Bootloader 未書き込みだと sketch 書き込みは「成功」するが何も起きない: LinkServer のログは正常終了するため，一見成功したように見えてしまう．
Burn Bootloader には Programmer 選択が必須(4章参照)．
Serial は物理UART(D0/D1)ではなくターゲットMCU自身のネイティブUSB(CDC ACM)にマッピングされている: variant の overlay で cdc-acm-serial = <&board_cdc_acm_uart>; となっている．Serial1(flexcomm4_lpuart4)も回路図上は"MCULINK"と明記されたMCU-Linkデバッグプローブ内蔵のUARTブリッジであり，こちらもArduinoヘッダの物理D0/D1ピンではない(詳細は付録参照)．デバッグプローブ(MCU-Link)用のUSBポートとは別に，ターゲットMCU側のネイティブUSBポートも別途PCに接続する必要がある．1本しか挿していないと Serial.println の出力がどこにも見えず，loaderの起動ログだけが見えて「Serial APIが壊れているのでは」と誤解しやすい．この対応関係はNXP/Zephyr/Arduinoいずれの公式ドキュメントにもまとまった一覧が無く，variants/frdm_mcxn947_mcxn947_cpu0/frdm_mcxn947_mcxn947_cpu0.overlay と回路図(FRDM-MCXN947SH.pdf)を直接読むのが一次情報源になる．他のインスタンス(I2C，SPIなど)を確認したい場合も同様．
プラットフォームの構文エラーは「board not found」という形で現れる: boards.local.txt / platform.local.txt のどちらかが壊れる(例: 誤った内容で上書きされる)と，該当ボードだけでなくプラットフォーム全体が読み込み不能になり，Invalid FQBN: board ... not found という一見無関係なエラーになる．arduino-cli core list でエラーが出るかどうかで切り分けられる．
bootloader.tool にも .default の対が存在する: upload.tool/upload.tool.default と同じ構造が bootloader.tool/bootloader.tool.default にもある．パッケージのバージョンやインデックスの更新で，上流の boards.txt 側の初期値が変わることがあるため，boards.local.txt では両方を明示的に上書きしておくのが安全．
boards.local.txt / platform.local.txt を編集したら，Arduino IDEを完全終了してから起動し直す: arduino-cli board details --show-properties では正しく新しい設定(linkserver)が解決されているのに，IDEのGUI経由では古い設定(pyocd)のまま実行される，という食い違いが複数回発生した．IDE 2.xは内部でarduino-cliのデーモンを常駐させており，ローカル設定ファイルの変更を実行中のセッションでは再読み込みしないことがある．ウィンドウを閉じるだけでは不十分で，Cmd+Q(Windowsではタスクトレイからの終了)による完全終了が必要．設定ファイルを変更した直後にビルド/アップロードがおかしい場合は，まずIDEの完全再起動を疑う．
while (!Serial); を書いたスケッチは，シリアルモニタを開くまでLEDすら点滅しない: この行はホスト側がUSB CDCポートをオープンするまで無限ループするイディオム．書き込み・loaderともに正常でも，シリアルモニタ(またはターゲットMCU側USBに対する何らかの接続)を開かない限り setup() の先(pinModeやloop())に進まない．「アップロードは成功したのにLEDが反応しない」という症状に遭遇したら，まずスケッチに while (!Serial); が無いか確認する．逆にこの「待ち」がない場合はシリアルを接続してなくても先に進んでくれるが，シリアルが準備できるまでの間に出力した文字が欠落する結果となる．

6. まとめ(チェックリスト)

Boards Managerで Zephyr Community Boards (BETA) をインストールし，FRDM-MCXN947 を選択
デバッグプローブ用・ターゲットMCU用のUSBケーブルを両方PCに接続
NXP LinkServer をダウンロード・インストール
boards.local.txt で upload.tool と upload.tool.default を linkserver に
platform.local.txt で tools.linkserver.* を定義し，アップロードにロードアドレスを渡す
tools/upload_linkserver.sh で LinkServer を検出し，FILE:ADDRESS 形式で flash ... load する
Tools > Programmer で何か選択してから Burn Bootloader を実行(loader書き込み．新品ボードでも必須)
LED点滅を確認
シリアルモニタで出力を確認(ターゲットMCU側のUSBポートを選択)

付録: 使えるインスタンス一覧(Serial / I2C / SPI / PWM / ADC)

frdm_mcxn947_mcxn947_cpu0.overlay(variants/frdm_mcxn947_mcxn947_cpu0/配下)のzephyr,userノードと，NXP公式の回路図(FRDM-MCXN947SH.pdf)を突き合わせた結果です．前述の通り，この対応関係をまとめた公式ドキュメントは無いため，これらの一次情報源を直接読むしかありません．

この節の内容は，記事の他の部分と異なり実機での書き込み検証を行っていません． overlayファイルと回路図の記載を突き合わせて導いたものであり，途中で一度(Serial1の物理ピンについて)誤りに気づいて訂正した経緯もあります．ピン配置とインスタンスの対応関係については詳細未確認として扱い，実際に使う際は各自の環境で動作確認してください．誤りに気づいた場合はコメント等で指摘してもらえると助かります．

Arduino API	実体(Zephyrラベル)	物理ピン / 備考
`Serial`	`board_cdc_acm_uart`	ターゲットMCU自身のネイティブUSB(CDC ACM)．デバッグプローブ用USBとは別ポート
`Serial1`	`flexcomm4_lpuart4`	回路図では`P1_8/FC4_P0_UART_RXD_MCULINK`・`P1_9/FC4_P1_UART_TXD_MCULINK`と，ネット名に"MCULINK"と明記されている．つまりMCU-Linkデバッグプローブ内蔵のUARTブリッジで，loaderの起動ログが出るのもここ．Arduinoヘッダの物理D0/D1ピンではない
`Wire`(I2C)	`flexcomm2_lpi2c2`	回路図で`P4_0/FC2_I2C_SDA-ARD_D18`・`P4_1/FC2_I2C_SCL-ARD_D19`と確認．Arduinoヘッダ標準のSDA/SCL位置(P4.0/P4.1)
`SPI`	`flexcomm1_lpspi1`	回路図で確認: `D11`(MOSI)=`P0_24`(`FC1_SPI_SDO`)，`D12`(MISO)=`P0_26`(`FC1_SPI_SDI`)，`D13`(SCK)=`P0_25`(`FC1_SPI_SCK`)，`D10`(SS)=`P0_27`(`FC1_SPI_PCS`)．Arduinoヘッダ標準のICSP位置
`analogWrite`(PWM)	未定義	overlayに`pwms`プロパティが無く，現時点では未対応
`analogRead`(ADC)	未定義	overlayに`io-channels`プロパティが無く，現時点では未対応

Arduinoヘッダの物理D0/D1ピンは，現状どのSerialインスタンスにも割り当てられていません． 回路図ではP4_3/FC2_UART_RXD-ARD_D0・P4_2/FC2_UART_TXD-ARD_D1と，flexcomm2_lpuart2に配線されていることが確認できますが，overlayのserialsプロパティにはこのインスタンスが含まれていません．つまり物理D0/D1ピンでシリアル通信をしたい場合，現時点のArduinoCore-zephyr変換では対応できないということになります．

digital pin(GPIO)についても限定的です．digital-pin-gpiosには

digital-pin-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>, <&gpio0 27 GPIO_ACTIVE_LOW>, <&gpio1 2 GPIO_ACTIVE_LOW>;

の3本しか定義されておらず，これはbuiltin-led-gpios(オンボードRGB LED)と全く同じ3本です．さらに回路図を確認すると，この3本は電気的にArduino Dピンとも共用されていることが分かりました．

GPIO	LED	共用しているArduinoピン
`gpio0 10`	LED_RED	`D9`(`P0_10/CT0_MAT0-ARD_D9`)
`gpio0 27`	LED_GREEN	`D10`(`P0_27/FC1_SPI_PCS-ARD_D10`)
`gpio1 2`	LED_BLUE	`D6`(`P1_2/CT1_MAT0-ARD_D6`)

つまり現状，汎用のDxピンとして使えるGPIOはオンボードLEDと共用のD6/D9/D10の3本のみで，シールドコネクタ上の他のピンはこのvariantではまだArduino APIから制御できる状態になっていません．Zephyr Community Boards (BETA)というベータ版の位置づけそのままの，現時点での対応範囲の狭さが見えてきます．

複数instance(Serial2やWire1など)は，このボードではserials/i2cs/spis各プロパティに1個ずつしか列挙されていないため存在しません．今後のアップデートでoverlayに追記されれば増える可能性があります．