コグノスケ

VSCodeでRISC-Vボードをデバッグその3 - Linuxマシン側の準備（Akaria BSP）

目次: Linux

前回はLinuxマシンだけを使って、OpenOCDとGDBでRISC-Vボードをデバッグする方法を紹介しました。

今回はそのおまけです。VSCodeのデバッグの話を見たい方はその4をご覧ください。

デバッグ対象: Akaria NS31 on Arty 7

デバッグ対象は何でも良いと書きました。その例として、別のソフトウェア、別のボードを使うパターン（Akaria BSP + NS31 on Arty 7）を紹介します。

• CPU回路データ: NSITEXEサイトへのリンクから取得できます。
• FPGAへの書き込み: Vivadoサイトへのリンクから取得できます。書き込むだけならVivado Labソリューションで十分です。
• ツールチェーン: GitHubへのリンクから取得できます。アーカイブへの直接リンクはこちら（riscv64-unknown-elf, Ubuntu 22用）です。
• ソースコード: GitHubへのリンクから取得できます。

FPGAへの書き込み方は以前の日記（2023年4月24日の日記参照）でご紹介しました。そちらをご覧ください。

ツールチェーンのインストールをします。ディレクトリはどこでも良いですが、ここでは~/workで作業しているものとします。

$ cd ~/work
$ wget https://github.com/nsitexe/akaria-riscv-toolchain/releases/download/nsitexe-20231117/riscv64-unknown-elf_ubuntu22.tar.gz
$ tar xf riscv64-unknown-elf_ubuntu22.tar.gz
$ export PATH=~/work/riscv64-unknown-elf/bin:$PATH

$ riscv64-unknown-elf-gdb --version

GNU gdb (GDB) 13.0.50.20220805-git
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

次にAkaria BSPのビルドをします。

$ git clone https://github.com/nsitexe/akaria-bmetal
$ cd akaria-bmetal/
$ rm -r build
$ cmake -B build -G Ninja -DARCH=riscv \
    -DCROSS_COMPILE=riscv64-unknown-elf- \
    -DCC=gcc \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DCMAKE_INSTALL_PREFIX=test/sysroot/ \
    -DDEFCONF=riscv_nsitexe_ns31_arty

CMake Warning (dev) at CMakeLists.txt:3 (project):
  cmake_minimum_required() should be called prior to this top-level project()
  call.  Please see the cmake-commands(7) manual for usage documentation of
  both commands.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/ccache/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/ccache/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is GNU
-- Found assembler: /usr/lib/ccache/cc
---- CC is 'gcc'
---- Compiler is 'riscv64-unknown-elf-gcc'
---- CCASM is 'gcc'
---- Assembler is 'riscv64-unknown-elf-gcc'
---- DEFCONF is 'riscv_nsitexe_ns31_arty'
---- CONF dir is '/home/katsuhiro/work/akaria-bmetal/config'
---- ARCH dir is '/home/katsuhiro/work/akaria-bmetal/arch/riscv'
---- SOC dir is '/home/katsuhiro/work/akaria-bmetal/arch/riscv/nsitexe_ns31'
---- BOARD dir is '/home/katsuhiro/work/akaria-bmetal/board/riscv/nsitexe_ns31_arty'
---- arch  is riscv
---- march is 'rv32imafc_zicsr_zifencei'
---- mabi  is 'ilp32f'
-- Found Doxygen: /usr/bin/doxygen (found version "1.9.4") found components: doxygen dot
-- Configuring done (0.3s)
-- Generating done (0.0s)
-- Build files have been written to: /home/katsuhiro/work/akaria-bmetal/build


$ ninja -C build install

ninja: Entering directory `build'
[46/47] Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/bin/add_auxdata
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/lib/libbmetal_crt.a
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/bmetal.h
-- Up-to-date: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/generated
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/generated/autoconf.h
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/generated/linker_gen.ld

テストアプリをビルドします。

$ cd ~/work/akaria-bmetal/test
$ make USE_NEWLIB=y

ビルドできました。1つ目の端末にてOpenOCDを起動します。

$ sudo openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f ./openocd-ns31.cfg

JTAGインタフェース用の設定ファイルtcl/interface/jlink.cfgはその2（2023年12月30日の日記参照）にてご紹介しています。SEGGER J-Link以外のインタフェースをご利用の場合は適宜変更をお願いします。

NS31 on Arty 7用の設定ファイルopenocd-ns31.cfgは以前の日記（2023年4月7日の日記参照）にてご紹介しています。

2つ目の端末にてGDBを使ってロード＆実行します。

$ riscv64-unknown-elf-gdb hello

(gdb) target remote :3333
(gdb) monitor reset halt
(gdb) load
(gdb) continue

UARTから出力されていることを確認します。

$ pyserial-miniterm /dev/ttyUSB1 9600 --raw

--- Miniterm on /dev/ttyUSB1  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
hello world!
good bye world!

Zephyr + HiFive1のときとロード＆実行方法は一緒です。最初はとっつきにくいかもしれませんが、OpenOCDとGDBの組み合わせであれば他のソフトウェア、他のボードでもほぼ一緒の使い勝手で便利です。

石川の大地震

鳥取4日目。2024年が明けました。今年もよろしくお願いいたします。

夕方、奥さんと外を散歩していたら風もないのに近所の家の窓がガタガタと10〜20秒？ほど揺れ続けました。何だ？と思う間に地震警報が発令され、能登半島で大地震があったことを知ったのでした。

地震の後のニュースでは（特にNHKの山内泉アナウンサーが顕著でした）逃げろ、高い場所に逃げろ、テレビなんか見てないで明るいうちに早く逃げろ！という切実な想いが伝わってきました。

ニュースは感情を煽らないのが通常です。しかし東日本大震災では避難を冷静に呼びかけたところ、津波の高さが想像できなかったのか避難が遅れて津波に巻き込まれて亡くなった人がたくさんいたそうです。

東日本大震災の悲しい教訓から、NHKは「今すぐ高いところに逃げること！」とやや感情的に呼びかけるようにした（「東日本大震災を思い出してください！」その時、ことばで命を守れるか。NHKアナウンサーたちの10年 - NHK）のだそうです。

NHKの取り組みは非常に良い取り組みだと思います。

羽田空港で大事故

早朝の便で東京に帰ってきました。

Twitterで羽田空港がどうこうと騒いでいる人がたくさんいて、何かあったのか？とニュースを見たら、羽田空港で日本航空機のエアバスA350と海上保安庁機のボンバルディアDHC8が滑走路上で衝突し、日航機が爆発炎上しているLive映像が流れていました。さっきまで居た羽田空港……だよな？炎上してる……。

A350は炎上してほぼ灰になったにも関わらず、400人もの乗客が全員脱出に成功して死者が一人も出なかったのは奇跡です。日本航空が日頃から安全を重視して取り組んでいる賜物だと思います。

それにしても2024年は1月1日から大災害、大事故が連続しており、何とも不安になるスタートですね……。

VSCodeでRISC-Vボードをデバッグその4 - SSH Remote ExtensionでGDBをボードにアタッチ

目次: Linux

前回はLinuxマシン単独でGDBを使ってRISC-Vボードのデバッグを行うところまでを設定しました。

今回はその続きで、Visual Studio Code（以降VSCode）とSSH Remote Extensionを使ってGDBをOpenOCDに接続しRISC-Vボードをデバッグします。

C/C++ Extension Packをインストール

C/C++デバッグ用のExtensionをSSH接続先にインストールします。C/C++ Extension Packをインストールしておくのが便利だと思います。

launch.json fileの作成

左側のActivity BarからRun and Debugを選択して（矢印1）、create a launch.json fileを押すと（矢印2）、デバッガを選べと言われるのでC++ (GDB/LLDB)を選択します（矢印3）。もしC++ (GDB/LLDB)が選択肢に現れない場合は、ソースコードウインドウを全部閉じてからもう一度やってください。

CMakeLists.txtを選択していた時に出るエラー

C言語ではないファイルを開いてRun and Debugやcreate a launch.json fileを押すと選択肢が変わるので注意してください。例えばCMakeLists.txtを開いてRun and Debugを押すと"CMake does not support automatic debugging for this file"とエラーが表示されるだけで何も起きません。

VSCodeは何もファイルを開いていなければ使用可能なデバッガを全て列挙し、開いているファイルがあればそのファイルに対して使用可能なデバッガだけを表示するようです。この仕様は初見だと分かりにくいですね……慣れたら便利なのかなあ？

Linuxマシン側の準備

詳細はその2（2023年12月30日の日記参照）にて紹介していますので、ダイジェストでお送りします。

ボードとSSH接続先のLinuxマシンを接続します。メニューの[Terminal] - [New Terminal]で1つ目の端末を開いてOpenOCDを起動します。

$ sudo openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f tcl/board/sifive-hifive1-revb.cfg

メニューの[Terminal] - [New Terminal]で2つ目の端末を開いてGDBを起動し、実行ファイルをロードします。launch.jsonの"program"で指定した実行ファイルをロードしてください。

$ riscv64-zephyr-elf-gdb build/zephyr/zephyr.elf

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load
(gdb) continue

UARTを見てRISC-Vボードが正常に動作していることを確認します。

$ pyserial-miniterm /dev/ttyACM0 115200 --raw

ここまで確認出来たらいよいよVSCodeからGDBを起動できます。長かったですね。

デバッガの設定

先ほど紹介したcreate a launch.jsonを選択するとGDBを起動する設定が生成されます。

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": []
}

が、バグっているのか何なのか、ほぼ何も書かれていないlaunch.jsonが生成されます。なぜ……？無いものは仕方ないので、

{
    "version": "0.2.0",
    "configurations": [        
        {
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/zephyr/zephyr.elf",
            "cwd": "${workspaceFolder}",
            "MIMode": "gdb",
            "miDebuggerPath": "/home/katsuhiro/work/zephyr-sdk/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gdb",
            "miDebuggerServerAddress": "localhost:3333",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
            ],
        },
    ]
}

上記のように変えます。デバッガのパス（miDebgguerPath）は適宜環境に合わせてください。

デバッガ起動

VSCodeのRun and Debugから先ほど作成した設定でデバッガを起動します。

デバッグ用のツールバー

デバッガが起動してOpenOCDに接続できるとVSCodeの上部に小さなツールバーが出てきます。出ない場合は下部にエラーメッセージが表示されるはず。

Pause後の画面の例

ツールバーのPauseボタン（左端）を押すと、HiFive1ボードの実行が停止して実行中のプログラムのソースコードが表示され、コールスタックの表示なども動作するはずです。ブレークポイントの設定や再開、ステップ実行などもできます。

私はCUIでもあまり困らないタイプですが、デバッガだけはGUIの方が見やすくて捗りますね。VSCodeのコード閲覧性が良いというのもありそうです。

できていない点

実質デバッガのアタッチしかできていません。ボードのリセット、実行ファイルのロードを端末から手動でやっている点が非常にイマイチです。

VSCodeのC/C++ Debugger Extensionは良く知らないので、VSCodeから実行する方法が判明したら追記しておきます。

令和6年能登半島地震災害への寄付

正月も元日から日本を揺るがした能登半島の震災ですが、令和6年能登半島地震災害義援金（日本赤十字社のサイト）、受付が始まってましたので寄付しました。何かの助けになると良いな……。

寄付したと言いふらすのは行儀が良くないと昔は思っていましたが、言いふらしても誰も不幸にならないし「みんなやってる」「みんなやろう」も広まるし、悪いことはないので積極的に言うようにしています。

メモ: 技術系？の話はFacebookから転記しておくことにした。追記あり。

M5Stackとesp32とArduino

目次: Arduino

M5Stackというボードが電子工作に便利らしいという話を聞き、M5 Core2とM5Stamp C3という小型のボードを買いました。Core2の方は機能豊富な分、お値段もそこそこ（8,000円くらい）します。M5Stampは安い（1,300円くらい）です。

開発環境

M5Stackのサイト（M5Stack document PLATFORMのページ）を見ると、AIなど特定用途向けを外すと開発環境は4つあるようです。多いなあ。派閥争い中でしょうか。

• UIFlow
• Arduino IDE
• Micropython
• .NET nanoFramework

1番目に表示されているUIFlowが一番おススメなのでしょうけど、残念ながらUIFlowはM5Stamp C3に対応していないようです。2番目に表示されていたArduino IDEにしました。Arduino IDEを使うなら素直にArduinoボードを買った方が良かったかな、まあいいか。

M5Stamp C3はデバッグできない

M5StackシリーズはいずれもEspressifのESP32ファミリーのSoC（IoT向けの小規模SoC）を採用しています。CPUとSRAM、一通りの低速系I/O I2C, SPI, I2Sなどの他に、Wi-FiやBluetoothに対応していて素晴らしいSoCです。無線技術に強いEspressifならではですね。

私が購入したM5Stamp C3はESP32-C3というSoCを採用しています。ESP32シリーズの中でC3は割と後発らしく、CPUが従来のXtensaではなくRISC-Vに変更されています。

新しいせいかCPUアーキを変更したせいか知りませんが、Arduino IDEでデバッグしようとしてもOpenOCDが繋がらないとエラーが出てデバッグできないです。ログを全部載せると長いので別ファイル（ ログ全部）にします。

Debug: 215 114 command.c:155 script_debug(): command - init
Debug: 216 115 command.c:155 script_debug(): command - target init
Debug: 217 115 command.c:155 script_debug(): command - target names
Debug: 218 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-flash-erase-start
Debug: 219 115 command.c:155 script_debug(): command - esp32c3 configure -event gdb-flash-erase-start reset init
Debug: 220 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-flash-write-end
Debug: 221 115 command.c:155 script_debug(): command - esp32c3 configure -event gdb-flash-write-end reset halt
Debug: 222 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-attach
Debug: 223 116 target.c:1659 handle_target_init_command(): Initializing targets...
Debug: 224 116 riscv.c:444 riscv_init_target(): riscv_init_target()
Debug: 225 116 semihosting_common.c:107 semihosting_common_init():  
Error: 226 131 esp_usb_jtag.c:642 esp_usb_jtag_init(): esp_usb_jtag: could not find or open device!    ★JTAGが見つからない？？
Debug: 227 131 command.c:545 run_command(): Command 'init' failed with error code -4
User : 228 131 command.c:608 command_run_line(): 
Error: 229 131 riscv.c:1755 riscv_get_gdb_arch(): Unsupported xlen: -1
Error: 230 131 esp_semihosting.c:67 target_to_esp_semihost_data(): Unknown target arch!
Debug: 231 131 riscv.c:490 riscv_deinit_target(): riscv_deinit_target()
Debug: 232 132 target.c:2225 target_free_all_working_areas_restore(): freeing all working areas

エラーの前後だけ切り出すとこんな感じです。JTAGデバイスが見つからんと言っているように見えますが、どうしたら良いか全くわかりません。しばらくはprintfデバッグするしかないようです。M5Stamp C3はM5Stackシリーズを初めて使う人が買うべきボードではなかった？？

ArduinoとESP32ライブラリ

M5Stackについて書かれたブログやコードを見ていると、外部ライブラリ（AdaFruit, Lovyan GFXとか）を使う場合と、Arduino-ESP32ライブラリを使う場合があるようです。

Arduino-ESP32ライブラリのドキュメントはEspressifが公開しています（Arduino-ESP32 2.0.14 documentation）。このライブラリはOSSでGitHubにてソースコードが公開されています（Arduino core for the ESP32 - GitHub）。

どうやってライブラリを入れ替えるのかわかりませんけど、Arduinoライブラリの中を見ることはできそうです。ありがたいですね。

Arduino-ESP32ライブラリはESP32 IDF（IoT Development Framework）というEspressif独自APIのライブラリを使用して実装されているようです。ドキュメントはやはりEspressifが公開しています（ESP-IDF Programming Guide）。GitHubにてソースコードも公開されています（Espressif IoT Development Framework - GitHub）。

このライブラリはちゃんと見てないですが、バイナリ（*.a）しかない部分もあって若干意味不明に見えます……。まあライブラリの表面だけだとしてもソースコードがあってありがたいです。きっと。

M5Stamp C3のAD端子

目次: Arduino

M5Stamp C3で遊んでいるとプログラムが妙に遅くなることがあって気になります。AD端子が関わっているようです。原因を調べてメモしておきます。

まず全力を見るためdigitalWrite()でGPIO出力のHIGH <-> LOWを往復させるだけのスケッチ（Arduinoはボードで動かすプログラムのことをスケッチと呼ぶ）を作成し、出力がHIGH区間の幅（＝ループ1回の処理に掛かる時間）をオシロスコープで計測したところ約7.6usでした。

M5Stamp C3のピン配置図（M5Stack社のサイトから転載）

M5Stamp C3のピン配置図を見るとA/D変換に対応した端子は0, 1, 4, 5の4つです。先ほどのスケッチにA/D変換対応端子の読み出し（＝処理が遅くなる容疑者）を順に追加して、同様にループ1回の処理に掛かる時間を計測します。

• digitalWrite()のみ: 7.6us
• analogRead(0): 64.0us
• analogRead(0), (1): 118.0us
• analogRead(0), (1), (4): 176.0us
• analogRead(0), (1), (4), (5): 20.8"ms"

どういう訳かanalogRead(5)だけが異常に遅く、読み出し値も常に0で正常動作していないように見えます。とりあえずこの端子は使わないことにしましょうか……。

もうひとつのA/D変換対応端子の読み出しAPIであるanalogReadMilliVolts()の時間も計測しましょう。読みだした値をmV単位に換算する処理が必要なので、処理時間はanalogRead() < analogReadMilliVolts()になるはずです。

• analogRead(0): 64.0us
• analogReadMilliVolts(0): 80.0us

割り算が要るのでそこそこ重い処理だと思いますが、16us（160MHz換算で2560クロック）も掛かるんですね。迂闊に連打しない方が良さそうです。

自分のドメインとGmailとDNSのSPFレコード

目次: 自宅サーバー

Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース（Gmailユーザへメールが届かなくなる？Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説！ - NRIセキュア ブログ）を思い出しました。

自分のドメインからGmailにメールを送ることはほとんどないですが、全く送れないのも困りそうです。試しにGmailに自分のドメインのメールアドレスからメールを送ったところエラーが返ってきました。もうポリシーが変更されているのでしょうか？

とりあえずDNSの設定を変更してSPF（RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1）レコードを追加します。送信元がメールサーバーのIPと一致しなければ、全部受信拒否してOKという強気の設定にしました（バリュードメインの設定パネル用の書式で書いています）。

txt @ v=spf1 ip4:219.94.129.142 -all

設定後しばらく待って（少なくともDNSのTTLに指定した秒数以上）からGmailにメールを送ったところ正しく届いていました。良かった良かった。

設定の意味がわからないときは

SPFレコードの設定を解説してくれているブログ（送信ドメインを認証するためのSPFレコードに詳しくなろう - SendGridブログ）が参考になりました。

活きた設定例を見たいときはプロバイダ各社のSPFレコードを見ると良いと思います。SPFはTXTレコードの一種なので、TXTレコードをDNSに問い合わせます。

$ dig wakwak.com TXT
（略）

;; QUESTION SECTION:
;wakwak.com.                    IN      TXT

;; ANSWER SECTION:
wakwak.com.             86400   IN      TXT     "v=spf1 ip4:211.9.226.0/25 ip4:211.9.226.128/26 ip4:211.9.227.0/25 ip4:211.9.227.160/27 ip4:211.9.230.0/23 ip4:211.132.128.0/23 ip4:211.132.130.160/28 ip4:211.132.130.132/31 ip4:211.132.130.208/31 ip4:219.103.130.0/24 ip4:219.103.131.128/26 ~all"

;; AUTHORITY SECTION:
wakwak.com.             73658   IN      NS      ns2.wakwak.com.
wakwak.com.             73658   IN      NS      ns1.wakwak.com.

;; ADDITIONAL SECTION:
ns1.wakwak.com.         37518   IN      A       211.9.226.37
ns2.wakwak.com.         37518   IN      A       211.9.226.101

理由はわからないですが、プロバイダのSPFレコードを見るとディレクティブ（レコードの最後の部分）に~allを使っていることが多いです。

今回はkatsuster.netのSPFレコードのディレクティブを-all（ルールに合致しなければ全部受信拒否）にしましたが、世の中のプロバイダ同様に~all（ルールに合致しなくても受信拒否しない）でも良いのかもしれません。

USB Type-C充電器の置き換え

USB Type-Cの充電器を3つほど購入しましたので、メモを残しておきます。

• Anker A2663113（Nano II 65W、USBポート: Cx1）
• Anker A2667N11（PowerPort III 3-Port 65W、USBポート: Cx2 + Ax1）
• ELECOM MPA-ACCP4465BK（USB Power Delivery 65W キューブAC充電器、USBポート: Cx2 + Ax1）

Anker Nano IIはLenovo ThinkPad E480のACアダプターを置き換えるために買いました。ThinkPad E480付属のACアダプタはやや大きいため、Nano IIのようなコンパクトな充電器はありがたいです。

Anker PowerPort IIIはスマホやタブレットの充電に長らく使ってきたAUKEY PA-Y12（72W Charging Station、USBポート: Cx1 + Ax2）の置き換えです。出力は負けますがコンパクトでありがたい限りです。時代の進化を感じます。

AUKEY Charging Stationに比べると、Anker PowerPort IIIはType-Aポートが-1でType-Cポートが+1です。以前ならType-Aポートが多い方が嬉しかったのですが、最近は我が家もType-Cでの充電に対応した機器が多くなって、AでもCでもどっちでも問題なくなりました。

ELECOMキューブ充電器は旅行で持っていく用に買いました。3ポートあるのにコンパクトでとても良いです。

ただ1点気になるのは、Type-CポートとType-Aポートの抜き差しを繰り返すとまれに充電制御がおかしくなる？現象です。Type-CポートのUSB-PD出力が5Vに張り付いてしまい、他のポートを空けても戻らなくなることがありました。コンセントから外して再度電源を投入すると直ります。何か条件があるのかな？

Windows Updateが0x80070643エラーで失敗し続ける

最近、家で使っているWindows 10 22H2にてWindows UpdateのKB5034441という更新のインストールにずっと失敗していて、毎回0x80070643というエラーが出ます。しばらく無視していましたが鬱陶しいので対策することにしました。

MicrosoftのサイトにあるKB5028997（KB5028997: WinRE更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順）によると、回復パーティションのサイズを250MB増やしなさいとのこと。

やたら手順が多く面倒なので、より簡単そうなKB5034957（KB5034957: CVE-2024-20666 のセキュリティの脆弱性に対処するために、展開されたデバイスの WinRE パーティションを更新する）を試しました。

KB5034957の説明によれば、

• スクリプトをPatchWinREScript_2004plus.ps1という名前で保存
• Update用の*.cabファイル（※）をダウンロード
• PowerShellから実行

だけで良いはずです。

（※）カタログ（Microsoft Updateカタログ）から2024-01 Dynamic Update for Windows 10 Version 22H2 for x64-based Systems (KB5034232)を探します。

実行したけどだめだった

やってみると下記のエラーで怒られますので、設定を変えなければいけないようです。

PS C:\users\katsuhiro\desktop> .\PatchWinREScript_2004plus.ps1

.\PatchWinREScript_2004plus.ps1 : このシステムではスクリプトの実行が無効になっているため、ファイル C:\users\katsuhiro\d
esktop\PatchWinREScript_2004plus.ps1 を読み込むことができません。詳細については、「about_Execution_Policies」(https://g
o.microsoft.com/fwlink/?LinkID=135170) を参照してください。
発生場所 行:1 文字:1
+ .\PatchWinREScript_2004plus.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : セキュリティ エラー: (: ) []、PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

エラーメッセージが示すリンク先（実行ポリシーについて - PowerShell | Microsoft Learn）を見ると、この問題を解決するには管理者権限で実行したPowerShellにて、Set-ExecutionPolicyで設定を変えなされとのこと。なるほど……？とりあえず現在の設定のRestrictedより制限を1つ緩めたRemoteSignedにしました。

PS C:\users\katsuhiro\desktop> Set-ExecutionPolicy RemoteSigned

実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies
のヘルプ トピック (https://go.microsoft.com/fwlink/?LinkID=135170)
で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "N"): y

PS C:\users\katsuhiro\desktop> Get-ExecutionPolicy

RemoteSigned

スクリプトを実行すると色々ログが出たあとに、Delete mount direcotryと出ました。成功したのかな？ちなみにもう1回実行しようとすると、前にもやっただろ？と言われて動作しません。良くできておりますね。

PS C:\users\katsuhiro\desktop> .\PatchWinREScript_2004plus.ps1

コマンド パイプライン位置 1 のコマンドレット PatchWinREScript_2004plus.ps1
次のパラメーターに値を指定してください:
(ヘルプを表示するには、「!?」と入力してください。)
packagePath: windows10.0-kb5034232-x86_3f9ddcafa903e4dd499193a851ecacbe79d842b3.cab
01/25/2024 03:36:11 - This script was previously run successfully

これで万事解決と言いたいところですが、更新KB5034441のインストールは未だに成功しません。ええー、だめじゃん……！

手動でパーティションを拡大

同じエラーが出ているということは、まだ回復パーティションのサイズが足りないのでしょうか？とはいえ先程使ったPowerShellスクリプトをもう1回実行しても、2回目は何もしません。

スクリプト改造するのもダルいので、観念して手動で回復パーティションのサイズを拡大したところ、あっさりWindows Updateが成功しました。パーティションサイズの拡大の手順は、先ほども挙げたKB5028997（KB5028997: WinRE更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順）の通りです。

KB503441インストール成功

Windows Updateが変なエラーで止まらなくなって、嬉しいは嬉しいですけど、回復パーティションはサイズが増え803MBになってしまいました。1GB近くも何を保存しているんでしょうね？？

Bluetoothドングル

目次: Arduino

PCとM5Stack/M5StampをBluetooth LEで接続したいと思って、Bluetoothドングルを購入しました。さほど高価ではない＆Linuxで動かないドングルがあるかも？と予想して、異なる商品を3つ買いました。Buffalo BSBT5D200（Bluetooth 5.0 + EDR/LE）、Buffalo BSBT4D200（Bluetooth 4.0 + EDR/LE）、Princeton PTM-UBT7X（Bluetooth 4.0 + EDR/LE）です。

一番新しいカーネルが動いているDebian Testing（Linux 6.5.13とBlueZ 5.71）のマシンで試してみましょう。

$ uname -a

Linux blackbird 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) x86_64 GNU/Linux

# bluetoothd --version

5.71

購入した3つのドングルそれぞれで、Bluetooth LEデバイスのスキャン（hcitool lescan）と、LEデバイス情報の取得（hcitool leinfo）を行ったところ、Bluetooth 5.0対応の一番新しいと思われるBSBT5D200だけ動きがおかしいです。悪い予想が当たってしまいました。

# hcitool -i hci0 leinfo (MACアドレス)

Requesting information ...
Could not create connection: Input/output error

BSBT5D200だけhcitool lescanが凄まじく遅いし、hcitool leinfo (MACアドレス)を実行するとI/Oエラーになります。あらら……。

幸いなことにBSBT4D200とPTM-UBT7Xは正しく動くので、しばらくこちらを使います。