Crescent

STM32H743ZIでCubeMXで生成したコードでRTOSなしでlwipを用いた通信ができないという不具合がありました。使用しているHALライブラリバージョンはSTM32Cube FW_H7 V1.7.0、CubeMX5.6です。統合開発環境はSW4STM32、v2.9です。

HALライブラリ内のサンプルプログラムは正常に動くものの、CubeMXで生成したファイルではEthenetが正常に動かず、pingが通らない状況でした。

コード等を完全にコピーしても不具合が治らないため、さらに原因をいろいろ調査すると...リンカスクリプトが原因と分かりました。プロジェクトファイル直下にCubeMXで生成されるSTM32H743ZITx_FLASH.ldです。

中身を比較テキストエディタ、WinMergeで確認すると不具合の原因が分かりました。

左が正常に動くリンカスクリプト、右がCubeMXで生成した不具合のリンカスクリプトです。

正常に動くサンプルプログラムはSTM32Cube_FW_H7_V1.7.0\Projects\NUCLEO-H743ZI\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS\SW4STM32\STM32H743ZI_Nucleoを参照しました。

lwipで使用するEthernet送受信領域がリンカスクリプト内で定義されていませんでした。そのため、未定義のままでEthenet正常に動かなかったようです。他にもリンカスクリプト内でヒープサイズ等の異なる点がありましたが、Ethenetの動作上は問題ありませんでした。

.lwip_sec (NOLOAD) : {
. = ABSOLUTE(0x30040000);
*(.RxDecripSection)

. = ABSOLUTE(0x30040060);
*(.TxDecripSection)

. = ABSOLUTE(0x30040200);
*(.RxArraySection)
} >RAM_D2 AT> FLASH

上記の定義をリンカスクリプトに追記すると正常に動作することが確認できました。CubeMX上でETHとlwipの設定をしているにも関わらず、リンカスクリプトに反映されないのはCubeMXの不具合だと思われます。今後のバージョンアップで修正に期待したいと思います。

RaspberrypiやTinkerboardといったシングルボードコンピュータ（SBC）ではOSを記録する媒体としてmicroSDカードやeMMCを使用しています。Win32DiskImagerといったツールでmicroSDカードやeMMCのバックアップを取った後に別のmicroSDカードやeMMCにリストアするとサイズ違いでエラーが発生し、リストアできない場合が時々あります。

microSDカードやeMMCは同じ容量でもロットやメーカによってセクタサイズが若干、異なります。小さい容量のバックアップデータから同じ容量もしくは大きい容量にリストアする場合は問題ありませんが、容量が小さい場合、エラーが発生して起動できません。パーティションに空きがあったとしてもパーティションサイズは不正なため、起動に失敗します。このような場合にはバックアップデータファイルのパーティションを操作とイメージファイルの編集が必要です。今回はバックアップしたイメージファイルをLinux(ubuntu)上で編集してOSイメージをリサイズする方法を紹介します。

■大まかな流れ

1. 縮小したいイメージファイル（*.img）をマウント

2. gpartedでドライブを縮小

3. 縮小して未使用の領域を除く

■手順

1. *.imgファイルをマウントするために空きのループデバイスを確認する。下記のコマンドで空いているループデバイス一覧が表示されます。

　　　sudo losetup -f

2. イメージファイル（*.img）を空きのループデバイスにマウントする。下記の例では空きのloop8にXXX.imgをマウントした場合を示す。

        sudo losetup /dev/loop8 XXX.img

3. ループデバイスを更新する。

　　　sudo partprobe /dev/loop8

4. パーティションを編集するためにパーティションツールを起動させる。

        sudo gparted /dev/loop8

　※gparted がインストールされていない場合は事前にsudo apt-get install gparted を実行しておく。

5. GUI上でドライブのext4パーティション(パーティション2)を右クリックし、[リサイズ/移動]をクリックする。右端をスライドさせてパーティションを縮小する。今回はセクタサイズの若干の差のため、数MiBでも大丈夫だと思いますが念のために100MiB~500MiB程度、縮小しました。

6. gparted の適用ボタンを押して変更を反映させる。

※この時点ではシステム上のパーティションサイズが小さくなっただけでイメージファイル（*.img）の容量は変わっていません。イメージファイルの未使用パーティションの空き領域をイメージファイルから削除する必要があります。

7. イメージファイルのパーティションセクタサイズを確認する。

    sudo fdisk -l /dev/loop8

　　　　　　　↑エル

　下記のように表示されます。Endのセクタ位置が重要です。パーティションの最終セクタの位置をメモします。

　　デバイス　ブート  Start   End      Block  Id   System

　　UUUUUUU         BBBB   CCCC    AAAA   *  Fat

　　WWWWW    *    YYYY   ZZZZ     AAAA   *  Linux

8. ループデバイスを解除する。(追記)

　 sudo losetup -d /dev/loop8

9. イメージファイルの空き領域を削除します。

         sudo truncate --size=$[(ZZZZ+1)*512] XXX.img

※重要な点は最終セクタから次の空き領域を削除するため、パーティションの最終セクタ+1を設定する点です。

これでイメージファイル（*.img）を縮小することができました。今回はVirtualBox上で実行したUbuntuでファイル操作を行いました。他にも専用スクリプトやresize2fsを使用する方法などありますが、環境によってうまくいかない場合がありました。上記の方法だと手間はかかりますが、RaspberrypiやTinkerboard、Nanopiといった様々なSBCでも適用できると思います。

先日、STから新しい開発支援ツール群STM32Cubeの１つとしてSTM32CubeMonitorが発表されました。STM32CubeMonitorはSTM32Studioの後継ソフトウェアという位置づけのようで、マイコンの変数や内部をリアルタイムに可視化してデバッグ効率を向上させることができます。早速使ってみました。

STM32CubeMonitorとSTM32 Studioとの大きな違いは、STM32CubeMonitorはUIにNode-Red組み込んだフローベースUIを採用している点です。STM32CubeMonitor v1.0時点では独自にカスタムされたNode-Redのため、配布されているノードを追加するといったことはできないようですが、dashboadのUI、シリアルノード、mqtt、tcp、httpといったよく使用するノードは予め導入されているため、困ることはなさそうです。

STM32CubeMonitorのWindows版をダウンロードしてインストールしてみました。STM32CubeMonitor起動前の注意点として、Node-Redを別で使用している場合は、同じポート1880を使用しているため、終了させる必要があります。個人的にはポートをNode-Red標準の1880から変えるべきだったと思います。

起動すると見慣れたNode-Redのフロー画面とデフォルトノードが出現します。

通常のNode-Redとの違いはSTM32CubeMonitor自身がブラウザとなってそのままフローエディタにアクセスできる点と独自のSTM32マイコンにアクセスするためのノードが用意されている点です。また、前述のフロー追加ができない点です。

標準フローには予めダッシュボードのグラフやボタンが含まれていました。STM32マイコンのデバッグをすぐに使用開始できるようになっています。

STM32CubeMonitorでSTM32マイコンのデバッグをするためにはSTM32Studio同様にビルドした際の生成ファイル(elfファイル等)とST-Linkで接続されたSTM32マイコンが必要です。

最初にSTM32CubeMonitorでモニタリングしたい変数を設定します。フロー中央のmyVariablesをクリックします。Executable項目のペンマークをクリックし、生成ファイルを登録します。

適当なNameをつけて、ビルドした際の生成ファイル(elfファイル等)のフォルダを指定します。STM32CubeMonitor v1.0時点では文字列としてフォルダを指定する必要があり、フォルダ選択画面は表示されません。Windowsの場合は別途、エクスプローラー等からワークスペース内のプロジェクトの生成フォルダ(Debugフォルダ)を確認し、文字列としてフォルダを指定します。フォルダを指定すると自動的にFileでelfファイルが表示されます。完了ボタンをクリックして設定を完了させます。

Variable Listにプロジェクトで使用している変数一覧が表示されます。今回はボタンを押した際にnumというグローバル変数を増加させるプログラムを書いてみました。必要に応じてVariable Listをフィルタして今回、モニタリングしたい変数numを選択します。

追加ボタンを押して設定を反映させます。

続いて、ST-Link設定を行います。フロー上のmyProbe_Outをダブルクリックし、Probe Configを設定します。ペンマークをクリックし、ST-Linkを追加します。PCに接続されたST-Linkが自動的にリストに表示されます。ここでST-Linkが表示されない場合はST-Linkを別のソフトウェアが占有していないか確認してください。STMCubeProgrammerやST-LinkUtilityを使用してSTM32マイコンにファームの書き込みをしている場合はDisconnectでST-Linkを事前に書き込みソフトウェアから解放する必要があります。

myProbe_Outの完了をクリックして設定を反映させます。同様にmyProbe_Inも設定します。一通り設定が完了したら、STM32CubeMonitor画面の右上の「DEPLOY」ボタンをクリックしてフロー設定を反映させます。「DASHBOARD」をクリックしてグラフを表示させ、「START Acquisition」をクリックすると先ほど指定したnumのモニタリングが開始されます。今回はボタンを押した際にnumというグローバル変数を増加させるプログラムを書いたのでボタンを押すとリアルタイムに変数が増加することを確認できました。

STM32Studioに比べてSTM32CubeMonitorはUIが簡素化され、非常に使いやすくなったと思いました。個人的には書き込みの度にST-Linkの切断、接続をするのが面倒でUARTをデバッグによく使用しています。ただ、UARTデバッグの問題点としてprintf等で出力する処理に時間を要するため、リアルタイム処理等の時間にシビアな処理の場合、printfが使用できません。このような場合もST-Linkを使用したSTM32CubeMonitorであれば、処理に影響せずにモニタできるため、非常に便利だと思いました。さらにUIがNode-RedになったことでCSVファイルの書き込みや読み込み、tcpやudp、httpが簡単に使用できるため、機械学習のデータ取り込みにも力を発揮できると思いました。