FRDM-MCXN947のボードを用いて、CAN通信の動作確認を行っていきます。
前回のCANループバック・テストに続き、今回はFRDMボード2台用いて、CAN通信の動作と、実際に送信されるCANフレームを確認してみます。
[CAN通信デモのイメージ]

目次
準備するもの
ハードウェア
・FRDM-MCXN947 (USBケーブル付属):2台
・ジャンパケーブル:2本
・CANのプロトコル・アナライザー (*オプション:CANの通信フレームを見たい方)

ソフトウェア
・FRDM-MCXN947用のSDK
*MCX N947向けのSDK(ver. 25.09.00)をVSCodeにインストールした前提で説明していきます。
開発環境(MCUXpresso for VSC)の準備、SDKのインストール方法は、以下の記事をご参照ください。
記事:MCUXpresso for VSCとSDKのインストール (日本語ブログ)
手順
1.CAN通信用のサンプル・アプリケーションをインポート
「File」メニューから「New Window」をクリックして、新しいワークスペースを作成

(前に別の作業を行っていたワークスペースだと、残っていた設定などで変な挙動をすることがあるため、新しいワークスペースで作業するのがオススメです)
サイドバーに表示される”PROJECTS"もしくは"QUICKSTART PANEL"内の「Import Example from Repository」をクリックし、下図の項目を選択/入力してください。
・Repository: 「インストールしたSDK」を選択
・Board: 「FRDM-MCXN947」を選択
・Template: 「driver_examples/flexcan/flexcan_interrupt_transfer_cm33_core0」 を選択
・Name: 任意の名前
・Location: 任意のフォルダを指定 *フォルダ名にスペースを含めないこと
・Toolchain: 任意のToolchainを選択 (今回はDefaultのArm GNU Toolchainを選択)

選択、入力が終わったら、「Import」をクリックします。
注:Templeteを選択する際に、3種類のCAN通信デモが表示されます。
1.flexcan_interrupt_transfer
2.flexcan_ping_pong_buffer_transfer
3.flexcan_pretended_networking_wakeup
違いは以下の通りです。今回は基本的なCAN通信の動作を確認したので、「flexcan_interrupt_transfer」を選択しました。
|
Example 名
|
主目的
|
使用する技術
|
主な用途
|
通信負荷
|
|
flexcan_interrupt_transfer
|
割込みベースの基本 CAN 送受信
|
割込み / コールバック
|
基本的な CAN 通信動作の確認
|
中
|
|
flexcan_ping_pong_buffer_transfer
|
複数 MB(メッセージ・バッファ) を使った連続通信
|
複数MB / 割込み
|
高負荷・連続 CAN 通信の
評価
|
高
|
|
flexcan_pretended_networking_wakeup
|
特定フレームでの Wakeup
|
Pretended Networking / Low Power
|
低消費電力設計、Wakeup 機能確認
|
低
(監視のみ)
|
注:MCUXpresso for VSCのバージョンに依っては、TemplateとNameの間に「App type」が表示される場合がありますが、こちらは何を選択いただいてもかまいません。
2.プロジェクト「flexcan_interrupt_transfer」の内容を確認
以下のようにPROJECTSに「flexcan_interrupt_transfer_cm33_core0」がインポートされました。

Project Files --> readme.mdを見てみると、このデモの概要と、対応しているボード一覧を確認できます。

[デモ概要を翻訳]
flexcan_interrupt のサンプルは、FlexCAN ドライバをノンブロッキングの割り込み方式で使用する方法を示す例です。
この例では、2 枚のボードを CAN バスで接続します。
エンドポイント A(ボードA)は、ターミナルでユーザーがスペースキーを押すと CAN メッセージを送信します。
エンドポイント B(ボードB)は、そのメッセージを受信し、内容をターミナルに表示した後、メッセージをエコーバックします。
エンドポイント A は、受信したメッセージの値をインクリメントし、次にユーザー操作による送信を待ちます。
[CAN周りの回路図を確認]
またCAN通信を行う場合に、CAN PHY (Transceiver)が搭載されているか、終端抵抗が付いているか等の確認が必要です。
FRDM-MCXN947の回路図を確認してみると、PHY、終端抵抗等も既に搭載されているため、このままJ10のヘッダピンから線を出せば、そのまま通信できそうです。

尚CAN PHYには、NXPの「TJA1057」が搭載されています。CANFDに対応しており、車載対応もできる製品です。
3.プロジェクトのビルド
先程インポートしたプロジェクトを右クリックして、「Build Project」を選択。

数秒でビルドが完了します。
ビルドが成功すると最後に"build finished successfully."と表示されます。

4.ターゲットボードへの書き込み
実際にPCとFRDM-MCXN947 2枚をUSBケーブルで接続します。
*1枚ずつ接続して書き込む方が簡単かもしれませんが、今回は敢えて2枚同時にPCに接続した例を説明します。
FRDMボードのUSBポートを左にした際に上側が書き込み&デバッグ用ポートとなります。

接続が完了したら、プロジェクトの右側に表示されている緑色の「▷」マークをクリック
ビルドとターゲットへの書き込みを実施します。

PCに2枚のFRDMボードを接続していたため、どちらに書き込むのか聞かれます。
ページ上部に表示されますので、書き込み対象を選択してください。

書き込み後、以下のような表示されます。

デフォルトで200行目にBreak Pointが貼られているので、プログラムがmain()の最初で止まっている状態です。
もう片方のボードにも書き込みを行います。
サイドバーに表示されるDEBUG PROBES内のLinkServerを確認すると、2台繋がっており、それぞれのSN(Serial Number)を確認することができます。
次に現在のProject > Settings > launch.jsonを開きます。
"probeSerialNumber"のパラメータに、先ほど接続していたボードの"EQ3WDUQLTZAHB"が設定されていますので、"PKXJ243RQDAQ1"に書き換えて保存します。

同様に書き込みを行えば、これでソフトウェアの準備は完了です。
5.CANの通信テストを行う

[デモの動き]
- ノードAからノードBに「ID: 0x321」を付与したCANフレームを送ります。
- ノードBは受信したデータと同じデータを「ID: 0x123」を付与してCANフレームを送り返します。
- ノードAは、次にフレームを送る際にデータをインクリメント(+1)して送ります。
これをPCから何かのボタンを押すたびに送受信を繰り返します。
[デモの動作確認]
実際にデモを動かしていきます。先ずはVSC上でシリアル・モニターの設定をします。PCに2枚のFRDMボードを接続されている状態で説明します。
- COMポートをFRDMボードが接続されているMCU-Linkのポートを選択します。(*Windows, Mac OSの違いにより、ポートの表示名は異なります。)
- Baud rateは、"115200"としてください。
- 設定したら"+Open an Additional monitor"をクリックして、同様にもう一つのモニターも設定します。

以下のように2つのシリアル・モニターが表示されました。
- 2つのモニターでそれぞれ"Start Minitoring"をクリックして、シリアル・モニターを開始します。

- 2つのモニターでそれぞれで"Toggle Terminal Mode"もクリックして、有効にしておくと、画面上から直接テキストを入力できるようなります。

それぞれのFRDMボードのリセット・ボタンを押すと、以下のようにデモのメニューが表示されました。2つとも同じソフトウェアが書かれているため、同じ画面となります。

先ずはどちらをノードBにするのかを設定します。その後、もう片方をノードAに設定します。
今回は画面左画をノードA、右側をノードBに設定しました。
- 画面右側に"b"を入力してノードBに設定
- 画面左側に"a"を入力してノードAに設定

ノードA(画面左)側から、「スペース」キーを入力してみると、ノードA、B共に送受信できたようです↓

試しに「スペース」キーを続けて何回か押してみると、送信の度にデータがインクリメント(+1)されている様子が確認できました。

プログラム上は問題なく動作していそうなので、実際に送信されたCANのフレームも確認してみようと思います。
6.実際のCANフレームをプロトコル・アナライザーで確認してみる
先ずタイムレンジを広くしてトリガーをかけてみると、2つCANフレームが送られていることが分かりました。

上図左側の波形を再取得してみると、フレームの初めにID: 0x321とあるため、ノードAからノードBへの送信フレームだと分かります。

右側の波形を再取得してみると、フレームの初めにID: 0x123とあるため、今度はノードBからノードAへ送り返したフレームだと分かります。

上図のCANフレームを拡大してみますと、こちらはCANFDのフレームであることが分かります。フレームの主な内容を解説しますので、そもそもCANFDフレームのフォーマットを忘れてしまった方は、以下の記事を併せてご参照ください。
記事:CANバス/プロトコルの概要と特長 (日本語ブログ)

[このフレームから読み取れる主なこと]
- IDは"0x123"です。プログラムからも選択するノードに依って、送信するIDが異なることが分かります。

- DLC = 0x8のため、CANFDでは"8バイト"のデータ長であることを意味します。実際にデータも8バイト分送られています。プログラム上でもDLC=0x8と設定されていました。

- DATA 1には"0x04"が入っています。0x00からデータを送るたびにインクリメントされるので、5回目に送信したデータであることが分かります。
- DATA2には"0x55"が入っています。こちらはプログラム上、固定値としていました。

- DATA3以降は"0x00"のデータが続きます。データが0x00なのに波形を見ると所々で"1"が立っています。これは正常な動きです。CANバス/プロトコルの概要と特長の記事でも説明しているとおり、「ビット・スタッフィング・ルール」(同じ論理レベルのビットが5回連続すると、スタッフビットと呼ばれる"5回連続したビットとは反対の状態ビット"が挿入される仕組み)が適用されているからです。
- 転送速度は、アービトレーション部(調停部)では500kbps、データフェーズでは、2Mbpsの設定としているようです。

まとめ
今回はデバイスとデバイス間でCANの通信行い、その通信フレームを取得して確認してみました。実際に自分でCANフレームを取得して見てみると、より理解が進むのではないかと思います。今回紹介しきれていないサンプル・アプリケーションもありますので、是非お試しください。
=========================
本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。
お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。
(既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。)