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月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) | 組込ソフト | このブログの読者になる | 更新情報をチェックする

2019年12月21日

STM32マイコン UART受信時必須処理

STM32マイコンでUARTの受信をする際に必須となるエラー処理について紹介します。

UARTの送信は一方的にマイコンから送るだけのため、そこまで大変ではありません。一方、受信は調歩同期方式ならではのエラー(フレーミング、バッファ オーバーラン エラー等)が発生するため、エラー処理を入れないとUARTの受信処理の安定性が悪化します。

更に厄介なのがSTM32マイコンのHALライブラリではUARTの受信割込みやDMA転送を使用した際に受信エラーが発生すると以降の受信処理が行われません。コマンドをUARTで処理する場合、受信エラー以降の受信が行われず、応答なし状態となっていまいます。

受信処理を継続して行うためにはエラー処理を加える必要があります。



実装としてはエラーが発生するとHAL_UART_ErrorCallbackが呼び出されます。
※設定によりますが、HAL_UART_ErrorCallbackが呼び出されないエラーがあったため、HAL_UART_ErrorCallback内でクリアせずにwhile内等でのクリア処理に変更しました。

UARTのエラーフラグを確認してクリアするHAL_UART_Abort関数を実行して受信処理を再開させます。
なお、HAL_UART_Abort関数は割込みを解除する関数ですが、各種エラーをクリアさせる機能も入っています。個々のエラーフラグだけをクリアするだけでは再開できないことが多々あるため、HAL_UART_Abort関数でレジスタをクリアさせる方法が確実です。



 if(huart->Instance==USART1){
  if (  __HAL_UART_GET_FLAG(&huart1, UART_FLAG_ORE) ||
    __HAL_UART_GET_FLAG(&huart1, UART_FLAG_NE) ||
    __HAL_UART_GET_FLAG(&huart1, UART_FLAG_FE) ||
    __HAL_UART_GET_FLAG(&huart1, UART_FLAG_PE) ){
     HAL_UART_Abort(&huart1);
     HAL_UART_Receive_DMA(&huart1, (uint8_t*)&UART_Data, 1);//DMAの場合
     //HAL_UART_Receive_IT(&huart1, (uint8_t*)&UART_Data, 1);//割込みの場合
  }
 }


上記処理をmain.cのwhile内等に配置することでエラー処理することができます。


以前に通常の処理ではうまく受信できるがタイミングによって受信できなくなるといった不具合に悩まされました。原因がフレーミングエラーと分かりました。電源投入直後のノイズ等でエラーが発生してしまったようです。上記の処理を加えることでエラー時に処理を再開させ、安定して通信を継続できるようになりました。

※一部HALライブラリ依存があったため、修正しました
posted by Crescent at 00:00| Comment(0) | 組込ソフト | このブログの読者になる | 更新情報をチェックする

2019年12月14日

STM32F3マイコンでの3線SPI通信


STM32F3マイコンの3線SPI通信で少し癖があったので少し紹介します。


CubeMX上ではHalf Duplex Masterとして設定します。

SPI.png



3線式ではHalf Duplexとなるため、HAL_SPI_Transmit関数とHAL_SPI_Receive関数を使用します。今回、読み込みコマンドをHAL_SPI_Transmit関数でデバイスに送信してから値をHAL_SPI_Receive関数で読み込みます。その際にHAL_SPI_Receive関数でタイムアウトエラーが頻発し、安定して読み込みできない現象が発生しました。



使用するバージョンにもよりますが、HALライブラリに少し癖があるようです。HAL_SPI_Transmit関数の後に続けてHAL_SPI_Receive関数を呼び出すとRXNEレジスタが変わらず、タイムアウト状態になってしまうようです。
※現時点ではSTM32Cube FW_F3 V1.11.0


3線式ではHalf DuplexではGPIOの入力、出力を随時切り替えて通信する必要があります。上記のタイムアウトを防止するため、強制的に入出力を切り替える関数を呼び出しすとタイムアウトエラーが発生せずに読み込めました。

具体的には下記の通りです。

SPI_1LINE_TX(&hspi1);//強制的に送信モード
HAL_SPI_Transmit(&hspi1,sdata,2,0x1000);
SPI_1LINE_RX(&hspi1);//強制的に受信モード
HAL_SPI_Receive(&hspi1,rdata,4,0x1000);



強制的な入出力を切り替えで読み込めることが確認できました。
posted by Crescent at 00:00| Comment(0) | 組込ソフト | このブログの読者になる | 更新情報をチェックする

2019年05月11日

STM32 Cube.AI 試食 その2 XOR

前回はSTM32 Cube.AIの紹介動画をベースに使い方を紹介しました。

前回は学習済モデルを使用したため、あまりAIやってる感がありませんでしたが、今回は実際の開発フローと同じように学習から推論まで行ってみました。

TensorflowとKeras、STM32Cube.AIを使って、XORの論理演算を学習させ、STM32マイコンで推論させてみました。
ターゲットマイコンとしてSTM32F747G-Discoveryを使用しました。

【準備物】

・STM32F747G-Discovery
・KerasとTensorflowインストール済みのPython3環境
・STMCubeMX5.1& Cube.AIパッケージv3.4
・SW4STM32やTrue Studioなどの開発環境


■PCでXOR論理演算学習
@XOR論理演算を学習させます。
 KerasとTensorflowインストール済みの環境でXOR.pyコードを実行します。
 「python XOR.py」
 学習させた結果、accが最終的に1になっていることを確認してください。
 0.75といったように1になっていない場合は何度か実行し直してください。

 また、最後に学習モデルを使って推論を実行しています。
 [0,0]、[0,1]、[1,0]、[1,1]をテストデータとしてそれぞれ与えており、
 0,1,1,0と表示されれば、XORの推論ができていることが分かります。


A学習モデルの保存
 コード実行後はコードと同じディレクトリにモデルがXOR.h5として保存されます。後でCubeMXで取り込んで使用します。

■CubeMXを使ったCube.AIプロジェクト作成
CubeMXにCube.AIのパッケージを追加する方法は前回の記事を参考にしてください。
@ターゲットボードの選択
 「Access to Board Selector」からSTM32F746G-Discoveryを選択します。


Aペリフェラル設定
 ボード選択後のペリフェラル設定はデフォルトモードyesを選択します。

 target-2.jpg



 「Computing」項目の「CRC」を有効化します。


 STM32F746DiscoはUSART1でPA9、PB7でSTLinkで接続されています。
 推論結果等をシリアルコンソールで表示するため、
 Connectivity→Usart1を有効化し、ボーレートを設定します。


 また、必要に応じてデバッグ用のSTLinkを有効化します。


CORTEX_M7をクリックし、IとDのCacheを有効化します。

 cubeAI-12.jpg

Bクロック設定
デフォルトは16MHzのため、最大の216MHzを入力します。
他の欄をクリックするとクロックウィザード確認がでるため、
OKボタンを押して他のクロックも合わせて自動設定します。


CCube.AIパッケージ追加
「Additional Softwares」をクリックして、X-Cube-AI/Application内の設定を有効化します。
 Coreライブラリにチェックを入れ有効化し、Applicationは「Application template」を選択して「OK」ボタンで画面を閉じます。



Dライブラリ設定
「Additional Software」に「X-CUBE.AI」が追加されます。
「X-CUBE.AI」をクリックして、「Artificial Intelligence Core」、「Artificial Intelligence Application」にチェックを入れて有効化します。


ECube.AI設定
「Additional Software」の「X-CUBE.AI」をクリックします。
「Add network」をクリックし、「XOR」モデルを追加します。
ライブラリに「Keras」、「Saved model」を選択し、先ほど学習させたModel「XOR.h5」を選択します。「Analyze」ボタンをクリックします。


 今回はXOR論理演算で簡単な処理のため、RAM40Byte、Flash:132Byteと圧縮なしでも非常に小さく実装できることが分かります。選択した学習済モデルで正常に推論できるか確認します。

 今回はXOR論理演算のため、ランダムを入力するよりも論理演算として想定されるデータを入れて確かめた方がよいため、「Validation from」からカスタムデータai_inputs.csv を選択します。
 「Validation on desktop」をクリックし、「Validation status」がSuccessとなれば正常に処理が終了したことを示します。

 下記のフォルダにアクセスして、ai_valid_outputs_model.csv、ai_valid_outputs_c_model.csvを確認してください。正常に処理が終了すると処理結果がcsvファイルとして出力されているはずです。

C:\Users\(ユーザー名)\STM32Cube\Repository\Packs\STMicroelectronics\X-CUBE-AI\(バージョン)\Utilities\windows

[1,1]の入力に対して約0.06
[1,0]の入力に対して約0.94
[0,1]の入力に対して約0.95
[1,0]の入力に対して約0.04



値を丸めると
[1,1]の入力に対して0
[1,0]の入力に対して1
[0,1]の入力に対して1
[1,0]の入力に対して0

ということでXOR論理演算の推論ができていることが分かります。

Fプロジェクト設定とコード生成
 HEAPサイズを0x200から0x2000に設定して、
他の設定は使用する開発環境等に合わせて設定し、
「Generate Code」をクリックします。

cubeAI-15.jpg

 なお、学習済データ等はMiddlewares\ST\AI\AI\data、Middlewares\ST\AI\AI\src
 Cube.AIライブラリ等はMiddlewares\ST\AI\AI\include、Middlewares\ST\AI\AI\lib
 ユーザーが呼び出す関数群はsrc\app_x-cube-ai.cに入っています。

 また、学習済モデルXOR.h5から推論の入力数、出力数は自動で設定されます。

Gprintf設定
CubeMXで生成したプロジェクトを開発環境にプロジェクトを追加します。
floatの結果を出力するため、プロジェクトのプロパティからいつも通り下記を追加して設定します。
-u_printf_float


ビルドします。

Hコード追記
main.c内に推論を行うための関数、コードを記述します。
今回はmain.cのみ手を加えました。
他のコードは自動生成されたコードです。
コードはこちらを参照してください。

code.jpg

aiTest()を呼び出して推論機能の初期化と実行をしています。
XORの学習モデルに合わせて入力に2次元の配列、出力に1次元の配列を与えています。
なお、自動で生成されるMX_X_CUBE_AI_Process()は空です。

Iマイコンへ書き込みと推論実行

xor-result.jpg

シリアルUartで出力させ、teratermでデバッグ表示させてみました。
学習させたXOR.h5モデルを使用してSTM32マイコン上で入力に対してXORの推論ができていることが分かります。


XOR論理演算を学習させてSTM32マイコンで推論させてみました。
XORモデルは非常に小さいため、ターゲットマイコンがSTM32F3シリーズでも実現できそうです。

今回はマイコン側のXORの入力は固定値ですが、スイッチ入力やセンサ、ADCなど変化する値にするとAIがより機能的だと実感できると思います。
例えば、入力を1x2でなく、もう少し大きな配列にしてアナログ値やセンサ入力等を学習させて、それに応じて音や光といった結果を返すことも実現可能です。

今回作成したコードとプロジェクトはこちらにアップしてあります。
今回はSTM32F7-Discoveryのディスプレイを全く使用していないため、今後はタッチパネルを活用して推論させたりしてみたいと思いました。
posted by Crescent at 00:00| Comment(0) | 組込ソフト | このブログの読者になる | 更新情報をチェックする