Armadilloフォーラム

> 大塩です。
>
> > 装置はArmadillo-IoT G3、Linux 4.9 AT22です。
> > 本事象も2年程前の書き込みがありましたDMA問題と考えればよいのでしょうか？
> > https://armadillo.atmark-techno.com/forum/armadillo/4289
> > それとも既に改修されており別問題と捉えるべきなのでしょうか？
> >
>
> Linuxカーネルat19 にて、RS485に関する修正が行われています。
> https://armadillo.atmark-techno.com/news/20210325/software-update-aiotg3
> お客様はすでにat21を使用されていますので、2年前と同様の問題である可能性は低いと思われます。
>
> > DMA問題の場合、パッチとして
> > https://armadillo.atmark-techno.com/comment/6525#comment-6525
> > を利用すればよいのでしょうか？
> > 試しにAT21に含まれていたimx.cに対して実行してみたのですがhunks Faild失敗してしまいます。
>
> パッチもかなり古いものなのでそのままでは当たらないようですが、手動での修正なら修正が可能と思われます。
> ダウンロードページのカーネルソースファイルをATDE7等の開発環境上に設置し、該当箇所を修正した後
> 製品マニュアル「Linux カーネルをビルドする」を参考にビルドすることでパッチを当てることが出来ます。
> https://armadillo.atmark-techno.com/resources/software/armadillo-iot-g3…

大分時間が空いてしまいましたが返信ありがとうございました。
アットマーク様の手厚いサポートもいただきなんとか解決しました。
※お陰様で自分でカーネルのビルドもできる様になりました。

やはり

https://armadillo.atmark-techno.com/forum/armadillo/4289

記載の小西様と同じようにimx.cを修正しDMAを使用しない事で安定動作しています。
対策前は2H程度で発生していた上記不具合が48Hの連続動作で発生しない事を確認しました。

環境は
Linux armadillo 4.9.133-at25
使用言語はC言語です。

使用したArmailloとRS485 I/Fは
AGX3144+OP-AGA-RS02-00
です。

前に書き込まれた方々との違いは当方のプログラムがスレッドを使用しているところでしょうか？
複数のスレッドの内の1つが問題のRS485通信を行っています。
このスレッドは他のスレッドとヒープ領域の変数を使ってデータのやり取りを行っています。
そしてMutexを使って排他制御を行っています。
当初デッドロックかと思ったのですが
・ソースを見返してもデッドロックが起こりそうなケースはないように見える。
　※排他制御の相手スレッドは一つしかなく、シンプルな制御に努めています。
・仕込んだprintfから問題のスレッドは通信が止まっても動き続けている事が確認できています。
・通信が止まった時はCloseに30秒程、時間が掛かってます。
以上から上記書き込みに行きつき今回の質問に至りました。

今提供できる情報はこんなところです。

波形観測やcat /proc/tty/driver/IMX-uartの変化、再現できる単純なコードなど傍証を集めることは
これから時間をかけてじっくりと…

とりあえず、ありがとうございました。