Segger Embedded Studio
以前こちらでSegger Embedded Studio上でnRF Connect SDK(以下NCS)を使う方法を紹介しました。
NordicとしてはNCSの開発はVisual Studio Code(以下VSC)を推奨しているようですが、僕がSegger Embedded Studio(以下SES)を使っているのはnRF SDK時代からずっとSESを使っているのと、今まで開発したものが残っているのでまだnRF SDKを完全に捨ててしまうわけにはいかないということからです。
共通で使えるIDEというのはそれなりに便利なものです。
めんどくさい
僕はVSCを使ったことはありません(でした)。
という状況において考えられることって・・・分かりますよね。だいたいにおいて新しいツールを習得するのってめんどくさいんですよ。ものすごくパワーがいるのです(笑)。
SESだって使えるようになるまでものすごくパワーを使いました。今ではほぼ隅々まで分かりますが、よく分かっていない時に謎のコンパイルエラーを出された時の虚無感などは筆舌に尽くしがたいものがあります。
いや、歳を取るとね・・・(笑)
そうも言っていられなくなった
ところが事件が起きます。それはMacbookで作業できな・・・いや、それもそうなのですが、NCSを扱う最大の理由はnRF5340を使うことだろうと思って長い間眠らせていた評価ボードを動かしていた時です。
hello_worldは動く、ヨシ！簡単じゃん！(笑)
次、Bluetoothはうご・・・あれ？動かない？
どうやらuart_init()は通っているようですが、そのあとのBluetooth Initializedまで動いていないようです。デバッガで追いかけてみるとbt_enable()でハングアップします。
void main(void)
{
int blink_status = 0;
int err = 0;
configure_gpio();
err = uart_init();
if (err) {
error();
}
if (IS_ENABLED(CONFIG_BT_NUS_SECURITY_ENABLED)) {
bt_conn_auth_cb_register(&conn_auth_callbacks);
}
err = bt_enable(NULL);
if (err) {
error();
}
LOG_INF("Bluetooth initialized"); ← ここまで来ていない
はて、なんでbt_enable()でハングアップするんだろうか・・・。もしかしてnetwork coreにうまく書き込みができていないとか？
ということでnRF5340のことを色々と調べました。
全ペリフェラルに単一アドレスでアクセスできる
全く何も分かっていない段階でまず最初に疑問に思うのは、コアが二つあってそれぞれにRAM/ROMがあるのだとすると、どうやってその二つのRAM/ROMにアクセスするのだろうか、ではないかと思います。それぞれの(FLASH)ROMがそれぞれのコアのファームウェアとして動くということは何らかの形で書き込んであげないといけないわけですが、どうやって分けて書き込むのか？
ということで仕様書をざ～っと見てみると単一アドレスでアクセスできるようになっているみたいです。つまり、よく分からないけれどきっとネットワークコアにもファームウェアが書かれているはず(笑)
なるほど、そういうことか！
念のため生成されたmerged.hexファイルの中身を見てみようっと。
:020000040000FA
:10000000...
:020000040001F9
:10000000...
:020000040002F8
:10000000...
:00000001FF
・・・。
:020000040100F9(ネットワークコアのFLASH ROMアドレス)で始まる拡張リニアアドレス指定がない？！ということは、控えめに考えて(笑)もネットワークコアのアドレスに書き込んでいる感じは全くありませんよね、これ・・・？
SESの不具合なのか・・・？
これがbt_enable()でハングアップする原因なのでしょう。だって、ネットワークコアのファームウェアがないんですもの。
もしかしてネットワークコアに書き込むためには何か特別な設定が必要なのだろうかと思って必死になって色々と探してみましたが、そもそもそんなことを試している記事など見つかるはずもなく、なぜ動かないのか途方に暮れておりました。
手順が足りていなかった・・・でも・・・
これは後から発見したのですが、SESではマルチコアのファームウェアを書き込むのを自動ではできないため手動で色々と追加してあげないといけないそうです。ここにその手順が書いてありました。
おっしゃ、これで解決だ！と思ったのも束の間・・・書かれている手順通りにやっていますがどうやってもうまくいきません。gccが走ろうとしてファイルがないと言われてしまいます。なんだこりゃ？
ということで再び諦めました(笑)
VCSではどうなんだろう？
考えても調べても全く解決策が思いつかないので、ふとVCSならどうなるのだろうと試してみることにしました。ちなみに過去にも何度か乗り換えようと思っては止めたのですが一念発起して動かしてみます！
nRF SDKはSESでNCSがVCSとツールを使い分けるのが面倒なだけです、ええ・・・w
いきなり躓く(？)
SESの方で使用したperipheral_uartを読み込ませると何やらエラーがドカドカ表示されます・・・orz
なんだよこれまともにプロジェクト始めることすらできないのかよと思ったのですが、どうやら無視できるようです。具体的にはLOG_WRNの引数が足りないみたいですがどう足りないのか調べていないので無視です(笑)
エラーが出っぱなしなのが気持ち悪いですが、コンパイルもダウンロードも普通にできるのでいざダウンロード・・・おっ、LEDが光り始めた！
VCSだとちゃんと動くようです。めでたしめでたし(笑)
nRF Connect for mobileでもちゃんと検出できて接続もできました。
試しにデータを送ってみましたがちゃんと送信できています。
ということで
さようならSES・・・キミのことは忘れない
いや、まだnRF SDKで使いますけどね(笑)