2020年03月28日

STM32H7 lwipの設定

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を参照しました。


winmerge.jpg

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

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

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

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

上記の定義をリンカスクリプトに追記すると正常に動作することが確認できました。CubeMX上でETHとlwipの設定をしているにも関わらず、リンカスクリプトに反映されないのはCubeMXの不具合だと思われます。今後のバージョンアップで修正に期待したいと思います。
posted by Crescent at 00:00| Comment(0) | 組込ソフト | このブログの読者になる | 更新情報をチェックする

2020年03月21日

SBC OSイメージリサイズ方法

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上でドライブのパーティションをクリックし、右端をスライドさせてパーティションを縮小する。今回はセクタサイズの若干の差のため、数MiBでも大丈夫だと思いますが念のために100MiB程度、縮小しました。

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 truncate --size=$[(ZZZZ+1)*512] XXX.img
※重要な点は最終セクタから次の空き領域を削除するため、パーティションの最終セクタ+1を設定する点です。


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

posted by Crescent at 00:00| Comment(0) | ナレッジ | このブログの読者になる | 更新情報をチェックする

2020年03月14日

STM32CubeMonitor

先日、STから新しい開発支援ツール群STM32Cubeの1つとして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のフロー画面とデフォルトノードが出現します。

cubemon1.jpg

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

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

cubemon2.jpg


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


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

cubemon7.jpg

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

cubemon3.jpg

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

cubemon4.jpg

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

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


cubemon6.jpg

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


cubemon5.jpg


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

2020年03月07日

Node-Redを用いたRTCの設定と読み込み

前回紹介したNode-RedからのI2Cデバイス制御する方法に続いて、応用例を紹介します。今回はDS1307搭載のRTCモジュールUSB-I2C変換アダプタを使用して、RTCの読み込みと設定をしてみました。


Arduino等でRTCモジュールを使用するプロジェクトとして時計やちょっとしたデータロガーなどが考えられます。このような用途では主要機能は時刻を読み込むだけなので、RTCモジュールに時刻を設定する方法が悩みどころです。パソコンから時刻をUARTで送信するか、ディスプレイとスイッチをつけるなど少し作りこみが必要です。個人レベルであれば、ベタでコードに時刻を書いて、Arduino等から書き込むといったことが多いと思います。

そこでUSB-I2C変換アダプタを使えば、PCから簡単にRTCモジュールに時刻を設定することができます。Node-RedがPC上で動いている特徴を生かして、時刻を書き込む際にはPC上の時刻をjavascriptで取得してRTCに書き込み仕様にしています。その都度、時刻を書き換えてRTCモジュールに書き込む必要がありません。


Node-Red_DS1307.jpg

読み込みはRTCから取得した情報をpayloadに格納してDebugに表示する仕様です。今回のサンプルコードはこちらで公開しています。活用してみてください。

なお、今回はDS1307を搭載したRTCモジュールを使用しましたが、個人的にDS1307を推奨しません。DS1307は時刻精度が悪く、数か月で数分以上時刻がずれます。また、チップのESD対策が悪く、コネクタ未接続状態、特に電池を外した状態で扱うと静電気ですぐに破損or動作不良になります。気づいたら時刻が読み込めない、時刻が書き込めない、変な値が読み出されるといった症状に悩まされます。
 DS1307の代わりに温度補償水晶発振器(TCXO)を内蔵したDS3231を推奨します。ピン配置、パッケージが異なるものの、DS1307とコマンド互換があるため、置き換え可能です。DS3231であれば数か月で数秒程度のずれに収まり、DS1307に比べてESD対策もされている感じです。

posted by Crescent at 00:00| Comment(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする