Skip to the content.

nRF5340 MDBT53-1M用のビルドがうまくいかない

2024/07/04

nRF5340の評価ボードnRF5340 MDBT53-1Mモジュールピッチ変換基板をスイッチサイエンスさんから購入した。

親切なことに使い方ガイドがある。 これを書いている時点では最終編集日は2023年9月1日。 手順通りにやって、プリコンパイル済みのzipファイルやhexファイルはUSBやJLinkを使って焼き、動くことが確認できた。
しかし、自分でビルドしたファイルを焼いても期待通り動作しなかった。


ビルドしたのは手順通り blinky である。LEDが定期的に点滅するだけでBLE機能など使っていないと思う。

記事との違いは、NCS(Nordic Connect SDK)のバージョンくらいか。 私は今の最新であるv2.6.1で記事はv2.4.0である。 NCSをインストールしているパスも違うが、そこは許容範囲内だろう(私はCドライブ直下にインストールしている)。

そしてこのバージョン違いが今回のうまくいかない原因であった。

Memory Map

以前はnRFgo Studio(だっけ)を使ってHEXファイルのメモリ配置を見ることができたような気がする。もしかしたら直接メモリを見ていたのかもしれないが。
今では、nRF Connect for Desktopから起動した「Programmer」を使って同じことができそうだ。

こちらが、私がビルドしたHEXファイルを焼いた後のメモリマップ。

image

こちらが、ビルド済みのHEXファイルを焼いた後のメモリマップ。

image

何もかもが違う・・・。
ビルド済みHEXファイルと私のビルドしたHEXファイルのレイアウトを並べてみよう。

image

多少サイズは違うが、NCSのバージョン違いによるものか? 一応Programmerで私のHEXファイルを焼いてみたが、やはりLEDは点滅しない。 「HEXファイルをProgrammerで焼く」「メモリレイアウトはだいたい同じ」なので、あとはもうHEXファイルそのものを疑うことになるか。

vscodeから ACTIONS > Flash で焼いた後に Programmer で READ するとこうなっていた。 上と下に分かれているが、これがコアを表している。上側がNetworkで下側がApplicationである。 先ほど見たときはApplicationコアだけしかなかったのだが、mcubootで焼いたんだったか?

image

Build Configuration

image

Build

ビルドすると、vscodeのTerminalにビルドのログが流れ始める。
以前は”nRF Terminal”というタブを使っていたようだが、今はTerminalに出力するようになっているようだ。
もちろんビルドは最後まで行われているのだが、WARNINGはいくつか出ている。
Terminalのログはモノクロで出力されるので、ERRORやWARNINGを探すのが結構つらい。

CMake Warning at C:/ncs/v2.6.1/zephyr/CMakeLists.txt:1957 (message):
  __ASSERT() statements are globally ENABLED
CMake Warning at C:/ncs/v2.6.1/nrf/subsys/bootloader/cmake/debug_keys.cmake:36 (message):
  

      --------------------------------------------------------------
      --- WARNING: Using generated NSIB public/private key-pair. ---
      --- It should not be used for production.                  ---
      --- See CONFIG_SB_SIGNING_KEY_FILE                         ---
      --------------------------------------------------------------
CMake Warning at C:/ncs/v2.6.1/nrf/cmake/partition_manager.cmake:79 (message):
  

          ---------------------------------------------------------------------
          --- WARNING: Using a bootloader without pm_static.yml.            ---
          --- There are cases where a deployed product can consist of       ---
          --- multiple images, and only a subset of these images can be     ---
          --- upgraded through a firmware update mechanism. In such cases,  ---
          --- the upgradable images must have partitions that are static    ---
          --- and are matching the partition map used by the bootloader     ---
          --- programmed onto the device.                                   ---
          ---------------------------------------------------------------------
warning: LOG_DEFAULT_LEVEL (defined at subsys/logging\Kconfig.filtering:13) was assigned the value
'0' but got the value ''. Check these unsatisfied dependencies: LOG (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_DEFAULT_LEVEL and/or look up
LOG_DEFAULT_LEVEL in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.
warning: The choice symbol MCUBOOT_LOG_LEVEL_INF (defined at
subsys/logging/Kconfig.template.log_config:17) was selected (set =y), but no symbol ended up as the
choice selection. See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUBOOT_LOG_LEVEL_INF
and/or look up MCUBOOT_LOG_LEVEL_INF in the menuconfig/guiconfig interface. The Application
Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of
the manual might be helpful too.
warning: The choice symbol LOG_MODE_MINIMAL (defined at subsys/logging\Kconfig.mode:28) was selected
(set =y), but no symbol ended up as the choice selection. See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LOG_MODE_MINIMAL and/or look up
LOG_MODE_MINIMAL in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.
CMake Warning at C:/ncs/v2.6.1/nrf/modules/mcuboot/CMakeLists.txt:382 (message):
  

          ---------------------------------------------------------
          --- WARNING: Using default MCUBoot key, it should not ---
          --- be used for production.                           ---
          ---------------------------------------------------------

ビルドログだけであれば特にダメそうなところはないような気がする。

ACTIONS > Debug

困ったらデバッグだ。
vscodeからはblinkyのmain.cしか見えないので、最初の方にブレークポイントを設定して ACTIONS > Debug を実行した。 これができなかったらどうしようもなかったのだが、幸い作動してくれた。

BOOT_LOG_ERR()の変数のうちデバッガで確認できた値はrc=-19image_index=0。 あとは最適化されていた。

image

メッセージで検索すると、こういうのが出てきた。-19なのは同じで ncs v2.6.1 なのも同じなので参考にできるかも。 ただ、これを書いている時点では解決していない。

Failed to open flash area ID 2 (image 0 slot 1): -19, cannot continue - Nordic Q&A - Nordic DevZone - Nordic DevZone

ncs v2.4.0 に戻す

使い方ガイドでは ncs v2.4.0 を使っている。ブートローダの仕様が変わったということがあってもおかしくない・・・のか?
ともかく、ToolchainとSDKにv2.4.0をインストールしてアクティブにする。

結果は・・・動いた!

image

うーん、まだまだ分からんことが多いのぅ。。。