Last Updated on 2026/08/13 by りょう
自作カスタムバックパネル（アルミCNC製）を装着して新鮮味が増したuConsole。
また、コントローラーボタンによるショートカット操作の復活や自作アクティブアンテナ（micro-whip系）との相性が良いことを実感出来て以前にも増して使用頻度が高まってきた。
起（突然の起動不可）
そんな或る時、いつもの様に満充電して早速使おうと電源をOnにして起動を待つ。
普段なら即座にデスクトップが表示されるのに、いつまで経っても画面は真っ黒なまま。
バッテリードアを開けて確認するとSSDへの給電はされていてHackerGadgets uConsole Upgrade Kitのバッテリーボードに有るLEDが赤色点灯しているがSSDのアクセスLEDは沈黙したまま。
一度電源をOffにして（電源ボタンではOffに出来ないため18650バッテリーを抜き挿しして強制断）、再度Onにすると、Raspberry Pi CM5に装着しているアクティブクーラーのファンが数秒回って停止し（これは通常時と変わらず）、SSDアクセスLEDが一瞬だけ点灯した（通常なら起動時には暫く点滅が続く）。
考えられるのはSSDの不調…使い始めたのは半年ほど前なのでそれほど経っていないが何が有るか分からないし。
全く同じSSDを外付けケースに入れてuConsoleのバックアップに使っているので、そのSSDと差し替えてみた。
電源をOnにすると無事起動しデスクトップも表示された…ただいつもより時間が掛かったような…。
承（何かおかしい…）
ひとまず無事起動した…と一安心して使い始めたら何かおかしい…。
操作に対するレスポンスが明らかに遅く、高頻度でプチフリーズしたかのように固まることが有る。
キーボードやトラックパッドなどの操作の他にも、コマンドラインで何か処理（例えばapt updateなど）をすると表示の最中で止まってしまいかなり待たされることが有る。
再起動やシャットダウンも以前より大幅に時間が掛かりハングアップしたかと思うほど。
交換したSSDはuConsoleの追加バックアップドライブ用につい先日新品購入したもので、その後のフルバックアップも問題無く行えた。
この極短期間で故障したとか初期不良は考えにくいけれど皆無とは言えず、念のためS.M.A.R.T.チェックを行った。
S.M.A.R.T.チェック…SSDは交換前後ともに健康そのもの
実装している（交換後の）SSDのS.M.A.R.T.情報を確認してみた。
先ず関連ツール「smartmontools」をインストールする。
sudo apt update sudo apt install smartmontools
インストールが完了したらコマンド実行。
sudo smartctl -a /dev/nvme0
冒頭に下記の表示が有ればひとまずOK。
SMART overall-health self-assessment test result: PASSED
他の項目にも異常は見られず健康そのもの。
一度uConsoleから取り外して外付けケースに収め、Windows11のCrystalDiskInfoでもチェックしたが、「正常：100％」「データエラー回数：0」「エラーログエントリー数：0」「クリティカルワーニング：0」でいたって健康だった。
もちろんuConsoleでの読み書きアクセスも問題無し。
交換前のSSDも外付けドライブにしてWindows11（CrystalDiskInfo）とuConsole（上記の「smartctl」コマンド）でチェックしたところ全く同じ結果で健康、uConsoleからの読み書きアクセスも正常に行えた。
つまり、交換前後いずれのSSDにも異常は無く、交換後の挙動不審もSSDが直接の要因というわけでは無さそう。
転（もしかしてバッテリー？）
プチフリーズの様な症状だけどSSDには異常が見られない。
遅かったり軽く固まったりするのを除けばアプリの起動や実行にも特に異常は見られない。
となるとハードウェア（コアや各種ボードなど）やソフトウェア（システム）が直接の要因ではない？
AIの助けを借りて要因を探ったところ「電力供給が不安定なのでは？」という点に行き当たった。
供給電力（電流）が規定を下回ると瞬断を起こしたり処理速度の大幅低下（コアのクロック速度が下がる、SSDが省電力モードへ移行しアクセス速度が低下する）が生じ、プチフリーズのような現象が発生する。
まさに今遭遇している症状と合う。
また、HackerGadgets uConsole Upgrade Kitのバッテリーボード経由で接続されたNVMe SSDは外部から給電されていても使用可能状態の内蔵バッテリーが必須のため、劣化したバッテリーを装着している状態では外部給電していても安定動作は期待出来ない。
（内蔵バッテリーが装着されていなかったり酷く劣化している場合はSSDの認識すらできない。）
これまで使っていたバッテリー
使用していたバッテリー（18650×2）は「KEEPPOWER P1835J 3.7V／3500mAh／保護回路付き」。
セル自体の最大電流は8Aだが保護回路が入っていて実際は6.2A程度。
uConsoleを入手した当時、ユーザーのブログ記事で勧められていたので選んだ物。
当時はコアがCM4でアクティブクーラーは未装着（純正バックパネルで放熱する構造）、NVMe SSDやAIO拡張ボードも実装していなかったので十分事足りていた。
その後、コアをCM5に換装しアクティブクーラーを装着して、NVMe SSDやAIO拡張ボードも実装し、消費電流は大幅に増えているが、残容量が10％程度まで下がっていても特に不調になることなく使用出来ていた。
それに満充電する直前までは問題無く普通に使えていた。
ただ、残容量（8割ほど）に対していつもより充電時間が長く掛かったのと、充電後のバッテリーの発熱も普段よりも多く、直接触れていないカスタムバックパネルのバッテリードア自体も（放射熱で？）少し温かくなっていた。
リチウム（イオン／ポリマー）バッテリーは経年や使用の劣化で突然使えなくなるというし、殊にuConsoleの様に消費電流（起動時やアクセス時のピーク値）が大きくて変動に敏感な機器ではより顕著なはず。
手持ちのスマート充電器「iSDT C4 evo」の分析モードでバッテリーの放電容量と内部抵抗を測定してみたところ、一本が2881mAh／78mΩでもう一本が2804mAh／87mΩ。
初期容量は3500mAhなので8割まで低下していて内部抵抗も高め。
一般的に初期容量の8割まで低下すると寿命（EOL）と判断され、内部抵抗が50mΩを超えると電圧降下や発熱が目立ち始めて高負荷での使用は要注意とされる。
また、放電容量が8割以上有っても内部抵抗が70mΩを超える場合も廃棄推奨。
つまり、このバッテリーはギリギリの綱渡り状態で使用出来ていたが、ついに劣化が進んで使えなくなってしまったようだ。
uConsoleと共に一年半使ってきて、特に直近の一年間はかなりの高負荷環境で満充電も頻繁に行ってきたことを考えれば、むしろもった方かもしれない。（長らく御苦労様）
次期バッテリー選定
取り出せる電流量が大きく（15A以上）、放電容量も或る程度多く（初期容量：3000mA以上）、保護回路が無い18650バッテリーの中で評価が高く国内での正規品を入手し易い「Murata 18650 VTC6」を選定した。
- 圧倒的な大電流（30A放電）への対応力
VTC6は最大で「30A」もの連続放電が可能なハイレート（高放電）セルであり、CM5、NVMe SSD、AIO拡張ボードV2（SDR／GPS／LoRa／USB 3.0／Gigabit Ethernet）が同時に最大パワーを要求するような超高負荷の瞬間（突入電流）が来ても電圧が一切ドロップせず、3.6V〜3.7V付近をグッと維持したまま安定してクリーンな電力をメインボードに供給し続けられる。
ちなみにKEEPPOWER P1835Jの出力電流は6.2A。（セル単体では8Aだが保護回路による制限で減少。） - 保護回路なし（生セル）による内部抵抗の低さ
これまで使用してきたKEEPPOWER P1835J（保護回路付き）が約50～70mΩ近くあったのに対し、新品のVTC6は「約10〜15mΩ」という驚異的な内部抵抗の低さを誇る。
電力を遮る「目詰まり（基板）」がないため、SSDの読み書きによる瞬間的なプチフリや、起動時のエラーの完全な解消が期待出来る。
また、uConsoleのバッテリーボードに保護回路が有るためバッテリーセル側の保護回路は不要になり、むしろ保護回路付きのバッテリーを用いた場合は「二重保護による電圧降下・内部抵抗の増加」「シャットダウンや動作不良の頻発」「物理的サイズ不整合※」といった弊害が生じる恐れが有る。
※保護回路付きのバッテリーは保護回路無しに比べて全長が5mmほど長くなるため、バッテリーホルダーへの負担が増す。 - 容量も3000mAhを確保
ハイレートな生セルは容量が2000mAh程度に犠牲になっていることが多いが、VTC6は「3000mAh」という高容量をキープしている。
これまでのKEEPPOWER P1835Jの3500mAhに比べるとスタミナ面でわずかに減るが、電圧の粘り強さが圧倒的なため、実用的な駆動時間としてはむしろこちらのほうが長く（安定して）使える可能性が高い。
結（無事解決）
本体の発熱対処でコッフェルの蓋（ステンレス製）を下に敷いている
スマート充電器（iSDT C4 evo）を使って新調した18650バッテリー（Murata/VTC6）を充電。
新品購入して最初なので、分析モード（満充電⇒放電⇒満充電）を使用し、放電容量と内部抵抗値の測定も併せて行った。
結果は、放電容量はそれぞれ2624mAhと2680mAhで初期容量（3000mAh）に対して9割近く有り、内部抵抗も50mΩと比較的低い値が確認出来た。
並列接続での使用なので二本の放電容量は極力違いことが望ましいが56mAhの差であれば問題無し。
内部抵抗も保護回路無しのセルにしては少々高め※だが正常の範囲内。
※連続して充電⇒放電⇒充電を行ったことでバッテリーが熱を帯びていることと充電器の端子との接触抵抗などで内部抵抗が高く見えている可能性有り。
分析モードが完了したので早速uConsoleへ装着して試用。
起動時間は以前通りに戻った。
コントローラーボタンでのショートカットでアプリケーションランチャーを起動し、そこから幾つかのアプリケーションを起動して使ってみて、プチフリーズ的な引っ掛かりは全く感じられない。
最後にシャットダウン…これも以前通りに。
起動（再起動）とシャットダウンは何らかのサービスが動いていて、その終了待ちで以前からたまに時間が掛かることもあるが、今回のトラブルでは比べ物にならないほどの時間が掛かっていた。（それこそフリーズを疑ったほど。）
つまり、無事復活♪
おそらく
18650バッテリーのようなLi-Ionバッテリーは、一般的な乾電池のように徐々に出力が低下するのではなく、ギリギリまで規定の出力を保ってから急降下する。
また満充電直後のような高出力の時には内部抵抗による電圧降下が起こり易く、今回のように満充電直後にはNVMe SSDからの起動が出来ないケースも有る。
暫く経つことで起動は出来ても既に劣化が進んでいるため、NVMe SSDへのアクセスなど高電流が要求される動作時には瞬間的に出力が落ちて、コアのクロック速度が大幅に下がったりSSDが省電力状態に入ることによるプチフリーズが発生したと考えられる。
今回のトリガーになった満充電を行う前日に二時間ほど外部給電（常時充電）しながらビルドなど割と高負荷の処理を行っていたが、それも劣化を進める要因になったのかもしれない。
SSDアクセス時の安定性向上
システム設定でNVMe SSDの省電力状態への移行やDRAM非搭載SSDのHMB機能を無効化することで、アクセス時の安定性を向上出来る。
一方で、SSDやPCIe関連の省電力機能を無効にするため消費電力が増加することと、HMBを無効にすることで大量データの書き込みやランダムアクセス時の処理速度低下といったデメリットが有る。
但し、消費電力の増加は少なく、速度に関してもRaspberry Pi CM5で「PCIe Gen2 x1」を設定していることからそちらでボトルネックになっていて実質的な影響は無く、逆にHMDの無効化でメインメモリへのアクセスが無くなるため消費電力と発熱の低下が見込める。
また、Raspberry PiのLinuxカーネルとDRAMレスSSDのHMB管理は相性が悪く、メモリ割り当ての失敗でシステムごとハングアップする恐れが有るが、HMBの無効化で回避出来るという大きなメリットも有る。
今までは特に必要と感じなかったけれど、バッテリーの消耗や劣化時のおまじないとして適用しておくことにした。
各種設定
sudo nano /boot/firmware/cmdline.txt または config.txt
nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off nvme.max_host_mem_size_mb=0
※既に別の設定が記述されている場合は、その行末にスペースひとつ空けて続けて記述する。（改行不可）
- nvme_core.default_ps_max_latency_us=0
・設定：NVMe SSDの深い省電力状態（APST: Autonomous Power State Transition）を無効化する。
・目的：低レイテンシの復帰に対応しきれない一部のSSDコントローラーが省電力モードに入ったまま応答しなくなる現象を防ぐ。 - pcie_aspm=off／pcie_port_pm=off※
・設定：PCIeリンクの省電力機能（ASPMおよびポート電源管理）を完全にオフにする。
・目的：Link State（L0s/L1など）の移行失敗によるフリーズや、高負荷時・アイドル時のリンク落ちを防止する。 - nvme.max_host_mem_size_mb=0
設定：DRAM非搭載SSDがホストのメインメモリの一部を借りる機能（HMB: Host Memory Buffer）を無効化する。
目的：特定のDRAMレスSSDのHMB実装とRaspberry PiのPCIeドライバ間での相性問題やメモリ割り当て失敗に起因するクラッシュを回避する。
今回使用しているNVMe SSD「シリコンパワー SP512GBP34A60M28」はDRAMレスタイプ。
※「pcie_port_pm=off」（PCIeポート電源管理の省電力機能オフ）は他の設定と比べて消費電力の増加がやや大きい反面効果はさほど大きくないため、バッテリー駆動時間が明らかに減少したと感じるのであれば除外してもよい。
反映（リブート）
sudo reboot
設定追記後の最初の起動はかなり時間が掛かる場合がある。
これは、直前までのプチフリーズ発生によるファイルシステムの自動修復や、HMBの無効化に伴うカーネルの初回メモリ再配置などによるもので、二回目以降が以前通りの起動時間であれば問題無し。
確認
システムへの読み込み
cat /proc/cmdline
下記の通り、全ての設定が読み込まれていることを確認する。（別の設定記述が有ればそちらも。）
nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off nvme.max_host_mem_size_mb=0
NVMeの設定（APST無効・HMB無効）
systool -v -m nvme_core && systool -v -m nvme
「systool」コマンドが使用出来ない場合は、下記を実行してインストール後にコマンドを使用する。
sudo apt update sudo apt install sysfsutils -y
出力されるテキストの中から下記の2行を検索し、値が”0″になっていることを確認する。
default_ps_max_latency_us = "0"
max_host_mem_size_mb = "0"
ASPM無効
lspci -vv | grep -i "ASPM"
出力結果の中に下記の記述が有ることを確認する。
ASPM Disabled
終わってしまえば単なるバッテリーの劣化だったわけだけど、今までに遭遇したことが無くて最初は本気で心底焦ったよ…。
いくらハードの予備やバックアップが有るとはいえ元の環境（構成）に戻す労力を考えるとね。
SSDを交換して起動した時は安堵したものの（結局、元のSSDは無実だった）、その後のプチフリーズ頻発でまた奈落落ち。
解決して本当に良かった。
原因の究明から対処方法、交換バッテリーの選定、対処後の改善方法や予防策など様々な点でAI（Google）には大変お世話になり心から感謝している。
写真（Leica M10-D、Ricoh GRⅢ）、アマチュア無線（JR4WDU）、デジタルガジェット、3Dプリント、ミリタリー（トイガン、小物）…などなど、興味の赴くままに広く浅く細く長く愉しんでいます。