yue110
2015年6月2日 17時03分
お世話になっております。
現在、armadillo460を使用しておりますが、
CON9の3ピンと5ピンを使用して調歩同期式で毎秒通信させているます。
通信としては、armadilloがマスターとなり、外部のICに送信し、
外部のICが応答という手順で処理しているのですが、
数日(3日や5日、9日など様々)動作させていると、
急にArmadilloが受信できなくなってしまいます。
CON9の3ピンと5ピンをあたると、
Armadilloからの送信や外部ICの応答データは正常に来ていることが確認出来ました。
そのため、外部ICからの応答データをarmadilloが急に受信できなくなってしまっているようです。
(受信割り込みが全く入らなくなってしまっています。)
また、オシロスコープ等で確認する場合、
どこをあたれば、どこまでデータが来ているかなど確認することが可能でしょうか？
※ソフトのバグも疑ってもおりますが、現在、同じファームで5台動作しており、
上記現象の出たArmadilloを別のものと入れ替えたりもしたのですが、
同じArmadilloでしか、現象が発生しておりません。
調査したいので、分かりましたら教えていただけないでしょうか？
宜しくお願い致します。
コメント
yue110
2015年6月3日 17時09分
at_kojiro.yamada 様
回答有難うございます。
>念のため、現象が「再現するArmadillo」 と 「再現しないArmadillo」で、
>それぞれに書き込まれているイメージ(bootloader, kernel, userland)が
>同じかどうか確認していただけないでしょうか?
現状は、試験的にConsoleにデバック用のコメントを出すように変更したものを書き込んだため、
userlandは一致していません。
しかし、始めに一致したもので試験し、この現象が出てたので、
Armadilloと結合している弊社作成の基板を入れ替え、同 userlandで試験しても同様に、今回の現象が出ました。
そのため、上記に記載したように、試験的にConsoleにデバック用のコメントを出すように変更したものを書き込み
試験しましたが、変らず今回の現象が出ました。
そこで、受信(割込み)が全く取れなくなってしまっていることが分かりました。
>まずは、問題発生時に
>カーネル内でデータを受信できているかどうか確認していただけないでしょうか?
教えていただきましたパッチを入れて試してみます。
ただ、再起動するため、また普通に動き出すので、その後何日か、十数日か？分かりませんが、
かかりますので、その結果が出ましたら、また記載いたしますので、よろしくお願い致します。
at_kojiro.yamada
2015年6月3日 17時27分
> 現状は、試験的にConsoleにデバック用のコメントを出すように変更したものを書き込んだため、
> userlandは一致していません。
> しかし、始めに一致したもので試験し、この現象が出てたので、
> Armadilloと結合している弊社作成の基板を入れ替え、同 userlandで試験しても同様に、今回の現象が出ました。
> そのため、上記に記載したように、試験的にConsoleにデバック用のコメントを出すように変更したものを書き込み
> 試験しましたが、変らず今回の現象が出ました。
> そこで、受信(割込み)が全く取れなくなってしまっていることが分かりました。
こちらは以下のコマンドで確認しても割り込み回数が増えていないような状況
でしょうか?
[Armadillo]# cat /proc/interrupts
> 教えていただきましたパッチを入れて試してみます。
> ただ、再起動するため、また普通に動き出すので、その後何日か、十数日か？分かりませんが、
> かかりますので、その結果が出ましたら、また記載いたしますので、よろしくお願い致します。
承知いたしました。
お待ちしております。
k.sato
2015年6月4日 9時23分
yue110と共同で作業しておりますsatoです。
重要なことが書かれていないので追記します。
シリアル通信ですがボーレートが460800bpsに設定したのですが受信データ抜けが発生したため
linux-2.6.26-at\arch\arm\mach-mx25\serial.hのUART3_DMA_ENABLEを1とし
DMAを許可しています。
これにより受信データ抜けは発生しなくなりました。
yue110が
> そこで、受信(割込み)が全く取れなくなってしまっていることが分かりました。
と言っていますが、正確ではありません。
select()で受信待ちをしているのですが10msでタイムアウトしています。
よろしくお願い致します。
at_kojiro.yamada
2015年6月5日 15時11分
> at_kojiro.yamada 様
>
> パッチを当てたカーネルを書き込んだのですが、
> コンソールに受信データが16進数で出力されません。
>
> これはDMAを使用しているからなのでしょうか？
そのようです。
DMAを有効化している場合でも受信データを表示できるようにした
パッチを作成しましたのでお試しください。
[PC ~/linux-2.6.26-at]$ ls print_recv_data_mxcuart3_for_dma.patch print_recv_data_mxcuart3_for_dma.patch [PC ~/linux-2.6.26-at]$ patch -p1 < print_recv_data_mxcuart3_for_dma.patch
| ファイル | ファイルの説明 |
|---|---|
| print_recv_data_mxcuart3_for_dma.patch | DMA対応版: UART3の受信データをログに出力するためのパッチ |
yue110
2015年6月22日 15時28分
at_kojiro.yamada 様
yue110です。
お世話になっております。
パッチを入れた状態で試験していましたが、納期まであまり時間もないことから、
先日より、別で確認しなければならないことなどあり、
一時的にパッチを入れていない状態で別の試験をおこなっておりました。
そのため、結果としてはまだ分かってはいないのですが、
パッチを入れた状態で試験している間は特に問題もでずに動作しておりました。(約10日間)
そのため、また時間を見て、パッチを組んだ状態での試験が出来るようになった時点で、
再度試験を行う予定ですので、そこで結果が出ましたら記載いたします。
誠に申し訳ありませんが、よろしくお願い致します。
yue110
2015年9月4日 10時36分
at_kojiro.yamada 様
大変お世話になっております。
長らくお待たせいたしました。申し訳ありません。
パッチを組み込んだ状態で動かし続けていましたArmadilloですが、やっと現象が発生しましたので、
状況報告いたします。
本日の今朝04：03：49頃まで受信できていたことは確認できていますが、
それ以降、受信が出来なくなりました。
本日の分だけを抜粋したパッチのデータを添付ファイルとして入れますので、
ご確認のほどよろしくお願い致します。
※1度の受信データが長いもので1300byte近くになっており、それを常時おこなっています。
そのため、データが長く見にくいかもしれません。申し訳ありませんがよろしくお願い致します。
※Armadilloがマスターとなり送信データ(要求データ)を送信し、
その応答データがArmadilloのCON9まで正常に来ていることは確認できています。
また、パッチの出力データ以外に、下記の様な表示がありますが、それは、弊社の使用しているの確認用データになります。
biff=X //確認用データ
//以下は通信がタイムアウトし、データが受取れていない状態を示しています。
[seri]SeriSendTimeout:stRecv.Sta=0 Fri Sep 4 04:03:49 2015
[seri]stSend.Time=506004799
[seri]stRecv.Time=506004791
[seri]CheckSendRetry:send retry=0 set retry=0
よろしくお願い致します。
| ファイル | ファイルの説明 |
|---|---|
| コンソール出力(軽量).log | パッチにより出力されたデータ(止まるしばらく前から抜粋) |
at_kojiro.yamada
2015年9月8日 14時25分
ご報告ありがとうございます。
添付していただいたログから、
Linuxカーネルが用意しているUARTの受信バッファ(TTY Flip buffer)まで
データが届いていないことがわかりました。
ソースコード(mxc_uart.c)の中でログを出力するように修正をいれたのは、
mxcuart_dmaread_callback()内のtty_insert_flip_string()の直前ですので、
以下の可能性が考えられます。
- TTY Flip bufferが満杯になっている
- Break Conditionが入力されている
- DMA転送が完了していない
カーネルのバグの可能性もありますので、こちらでも問題を再現させ、
詳しく調査したいと考えております。
問題再現のため、以下の情報を教えていただけますと助かります。
- シリアルの設定と送受信をどのように行っているか
- もし可能であれば、問題再現時のソースコード
- カーネルコンフィギュレーション※
※問題が再現したArmadilloから、/proc/config.gzをUSBメモリなどでPCに
コピーしてフォーラムに添付していただくのが良いかと思います。
カーネルのバグの調査は時間がかかってしまうので、
カーネル以外が原因となる可能性について記載します。
■ select()のタイムアウトが短すぎる可能性はないでしょうか？
> armadilloがマスターとなり、外部のICに送信し、
> 外部のICが応答という手順で処理しているのですが、
とのことですが、
上記手順が10ms以内に完了しない場合があるのかもしれません。
例えばの話ですが、
連続で10回タイムアウトするまでselect()で待つようにしたら、
1回や2回タイムアウトして後でread可能になったりはしないのでしょうか？
k.sato
2015年9月8日 16時59分
at_kojiro.yamada 様
k.satoです。
お世話になっております。
ソースを添付しますので、
見辛いですが確認をお願い致します。
シリアルの設定
/dev/ttymxc2
ボーレート：460800bps
データビット：8
ストップビット：1
パリティ：なし
フロー制御：なし
DMA：有効化
DMAバッファサイズ：2048バイト
送受信のシーケンスは
１．秒が変更されたとき送信コマンドバッファに取得コマンドを4ユニット分追加します。
２．通信のメインループで送信可能なとき送信コマンドバッファにコマンドが存在するとき1コマンド送信します。
３．通信のメインループでselect()を使用し受信を確認します。(select()のタイムアウトは10ms)
４．受信コマンドが正常、異常または送信して500ms(カーネルで受信データを出力するため長い)経過したとき
送信コマンドバッファを進めます。
５．4ユニット分のデータの取得が完了したとき4ユニット分のデータをSDカードに保存します。
６．５が完了したとき１に戻ります。
SDカードへの保存と通信を分けたのは
同時に処理をしたときに受信データ抜けがあったためです。
> 例えばの話ですが、
> 連続で10回タイムアウトするまでselect()で待つようにしたら、
> 1回や2回タイムアウトして後でread可能になったりはしないのでしょうか？
この現象が出たら復帰しないです。
復帰させるには再起動もしくは通信の設定を初期化、再設定する必要があります。
※タイムアウトが出やすい現象をわざと作っていたので、この現象が出るまでは、
記載通り、数回タイムアウトして復帰となっていました。
また、同様のユーザランドを書き込んだ装置2台を試しましたが、
(パッチは入れていないが、その前に現象が出たもの)
そちらは、この現象は出ていません。
以上、よろしくお願い致します。
| ファイル | ファイルの説明 |
|---|---|
| syukei_seri.c | シリアルのソースファイル：通信とSDカードへの保存を行う |
| syukei_seri.h.txt | シリアルのヘッダファイル |
| config.gz | カーネルコンフィギュレーション |
at_kojiro.yamada
2015年9月28日 19時36分
反応が遅くなってしまい申し訳ありません。
現状、こちらでは問題が再現しておりません。
「Armadillo-460 CON9までデータが来ているが、
Linuxカーネル内のTTY Flip bufferまでデータ来ていない」
ということから、
UART3のRXEN(Receiver Enable)が無効化されている、
もしくは、割り込みが無効化されている等の
Linuxカーネルのバグを疑っております。
切り分けのため、
問題発生時のUART3関連のregisterの値をダンプしたいと考えておりますが、
こちらで問題を再現できておらず、再現できる確証もありません。
そのため、お手数おかけいたしますが、
後述する手順を実施して、read_imx25_uart3_reg.shの実行時のログをフォーラ
ムに添付していただけないでしょうか？
■手順
1. 問題を再現させる
2. 問題を再現させた状態で、Armadilloにログイン
3. 添付したread_imx25_uart3_reg.tar.gzを/rootに配置
4. 送受信プログラムは動作させたまま、下記コマンドを実行
[Armadillo]# ls read_imx25_uart3_reg.tar.gz read_imx25_uart3_reg.tar.gz [Armadillo]# tar xzf read_imx25_uart3_reg.tar.gz [Armadillo]# chmod +x read_imx25_uart3_reg.sh devmem2 [Armadillo]# ./read_imx25_uart3_reg.sh
以上、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| read_imx25_uart3_reg.tar.gz | devmem2およびUART3関連のregister値をダンプするスクリプト |
at_kojiro.yamada
2015年9月29日 20時59分
ご報告ありがとうございます。
1点、お伝えし忘れており申し訳ありませんが、ご報告いただいたログを取得し
たArmadilloは、可能な限り電源を落とさず、問題発生直後の状態を維持してい
ただくようお願いいたします。
ダンプ結果を見ると、
UART3の受信側のFIFOにread可能なデータがあるようですが、
その他特に異常な点は見当たりませんでした。
FIFOに入っているデータを確認するため、
下記手順を実施していただき、実行時のログをフォーラ
ムに添付していただけないでしょうか？
■手順
1. 添付したread_imx25_uart3_recv_reg.shをArmadillo上の/rootに配置
2. 送受信プログラムは動作させたまま、下記コマンドを実行
[Armadillo]# ls devmem2 read_imx25_uart3_recv_reg.sh devmem2 read_imx25_uart3_recv_reg.sh [Armadillo]# chmod +x devmem2 read_imx25_uart3_reg.sh [Armadillo]# ./read_imx25_uart3_recv_reg.sh
以上、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| read_imx25_uart3_recv_reg.sh | UART3のreceive registerをダンプするスクリプト |
ym1909
2015年9月30日 11時37分
yue110、satoと共同で作業しておりますym1909と申します。よろしくお願い致します。
read_imx25_uart3_recv_reg.shの実行結果は以下のようになりました。
-------------------------------------------------------------------------
addr : data
0x5000c080 : 269
0x5000c084 : 20519
0x5000c088 : 4
0x5000c08c : 32768
0x5000c090 : 17104
0x5000c094 : 9040
0x5000c098 : 21163
recv reg 0 : 32770
recv reg 1 : 32771
recv reg 2 : 32771
recv reg 3 : 32850
recv reg 4 : 33023
recv reg 5 : 32771
recv reg 6 : 32909
recv reg 7 : 32832
recv reg 8 : 32770
recv reg 9 : 32772
recv reg 10 : 32771
recv reg 11 : 32850
recv reg 12 : 32789
recv reg 13 : 32777
recv reg 14 : 32772
recv reg 15 : 32772
recv reg 16 : 32771
recv reg 17 : 32841
recv reg 18 : 32817
recv reg 19 : 32768
recv reg 20 : 32768
recv reg 21 : 32768
recv reg 22 : 32768
recv reg 23 : 32768
recv reg 24 : 32768
recv reg 25 : 32768
recv reg 26 : 32768
recv reg 27 : 32768
recv reg 28 : 32768
recv reg 29 : 32768
recv reg 30 : 32768
recv reg 31 : 57344
recv reg 32 : 32770
recv reg 33 : 57348
recv reg 34 : 57344
recv reg 35 : 32770
recv reg 36 : 32775
recv reg 37 : 32771
recv reg 38 : 32850
recv reg 39 : 32789
recv reg 40 : 32777
recv reg 41 : 32816
recv reg 42 : 57361
recv reg 43 : 57344
recv reg 44 : 32770
recv reg 45 : 32776
recv reg 46 : 32771
recv reg 47 : 32850
recv reg 48 : 32789
recv reg 49 : 32777
recv reg 50 : 32816
recv reg 51 : 57361
recv reg 52 : 57352
recv reg 53 : 32770
recv reg 54 : 32771
recv reg 55 : 32771
recv reg 56 : 32850
recv reg 57 : 33023
recv reg 58 : 32771
recv reg 59 : 32909
recv reg 60 : 57408
recv reg 61 : 32770
recv reg 62 : 32772
recv reg 63 : 32771
recv reg 64 : 32850
----------------------------------------------------------
以上、よろしくお願い致します。
at_kojiro.yamada
2015年9月30日 17時01分
ご報告ありがとうございます。
ダンプ結果を見る限り、
UART3の受信側のFIFOには、データが格納されているようです。
ダンプした値は16ビットあり、
上位8ビットにはフラグ(errorが起きたかどうかや、データが有効かどうか等)、
下位8ビットにはデータが格納されます。
最上位ビットが1であれば、下位8バイトに有効なデータが格納されています。
ダンプした値を16進数に直し、データ部だけ取り出すと
02030352ff038d40...
というデータが受信されており、これと同じデータ列が以前添付していただいた
"コンソール出力(軽量).log"
の中にも見られます。
次はttyの設定とcatでデータを取得できないかを確認したいと考えております。
問題再現中のArmadillo上で、以下の手順を実施し、
「最初のsttyコマンド実行」から「Ctrl+Cを押下」までのログと
cat /dev/ttymxc2 > recv_data.logで生成した
recv_data.logファイルをフォーラムに添付していただけないでしょうか？
■手順
1. 送受信プログラムは動作させたまま、下記コマンドを実行
[Armadillo]# ls devmem2 read_imx25_uart3_recv_reg.sh devmem2 read_imx25_uart3_recv_reg.sh [Armadillo]# chmod +x devmem2 read_imx25_uart3_reg.sh [Armadillo]# stty -F /dev/ttymxc2 -g [Armadillo]# stty -F /dev/ttymxc2 -a [Armadillo]# cat /dev/ttymxc2 > recv_data.log & [Armadillo]# ./read_imx25_uart3_recv_reg.sh [Armadillo]# fg [Armadillo]# Ctrl+Cを押下
以上、よろしくお願いいたします。
■参考: UART3の受信側のFIFOダンプ結果(16進数表記)
8002 8003 8003 8052 80ff 8003 808d 8040 8002 8004 8003 8052 8015 8009 8004 8004 8003 8049 8031 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 8000 e000 8002 e004 e000 8002 8007 8003 8052 8015 8009 8030 e011 e000 8002 8008 8003 8052 8015 8009 8030 e011 e008 8002 8003 8003 8052 80ff 8003 808d e040 8002 8004 8003 8052
ym1909
2015年9月30日 17時39分
お世話なっております。ym1909 です。
コマンドを実行した結果をテキストファイルに添付いたしました。recv_data.logとともに添付ファイルでお送り致します。
ご確認の程、よろしくお願い致します。
| ファイル | ファイルの説明 |
|---|---|
| 実行結果コンソール出力.txt | |
| recv_data.log |
yue110
2015年10月1日 9時44分
お世話になっております。
本回答に追記いたします。
下記で手順に間違いないか、ご確認ください。
at_kojiro.yamada様に記載していただきました、
:2015/09/29 - 20:59のコメントの手順と、:2015/09/30 - 17:01のコメントの手順ですが、
両方ともに
chmod +x devmem2 read_imx25_uart3_reg.sh
といった権限を与えるコマンドがありますが、
この「read_imx25_uart3_reg.sh」ですが、
そのままでやるとエラーで弾かれてしまうため、
前後の文面から推測し「read_imx25_uart3_recv_reg.sh」の誤りではないかと思い、
そちらで確認していたのですが、間違えないでしょうか？
また、もう一点お聞きしたいのですが、
:2015/09/30 - 17:01のコメントに
cat /dev/ttymxc2 > recv_data.log &
とありますが、最後の & は何のためについているのでしょうか？
この＆が良く分かりませんでしたので、教えていただけないでしょうか？
よろしくお願い致します。
at_kojiro.yamada
2015年10月1日 12時18分
> at_kojiro.yamada様に記載していただきました、
> :2015/09/29 - 20:59のコメントの手順と、:2015/09/30 - 17:01のコメントの手順ですが、
> 両方ともに
> chmod +x devmem2 read_imx25_uart3_reg.sh
> といった権限を与えるコマンドがありますが、
> この「read_imx25_uart3_reg.sh」ですが、
> そのままでやるとエラーで弾かれてしまうため、
> 前後の文面から推測し「read_imx25_uart3_recv_reg.sh」の誤りではないかと思い、
> そちらで確認していたのですが、間違えないでしょうか？
おっしゃる通りで、
[Armadillo]# chmod +x devmem2 read_imx25_uart3_reg.sh
は誤りです。
申し訳ありません。
推測していただいた通り、正しくは
[Armadillo]# chmod +x devmem2 read_imx25_uart3_recv_reg.sh
となります。
>
> また、もう一点お聞きしたいのですが、
> :2015/09/30 - 17:01のコメントに
> cat /dev/ttymxc2 > recv_data.log &
> とありますが、最後の & は何のためについているのでしょうか？
> この＆が良く分かりませんでしたので、教えていただけないでしょうか？
catが/dev/ttymcx2を読み出しし続けると、
read_imx25_uart3_recv_reg.shを実行させられないので、
& を付けて catをバックグラウンドで実行させておりました。
ここでは、catでデータを受信しようとしている間でもUART3の受信側のFIFOに
データが溜まっているかどうかを確認することを意図しております。
ご報告いただいたログについて記載します。
ttyの設定には問題が無いように思います。
ただ、min = 0;と設定されていたため、
catが/dev/ttymxc2からデータを読み出さずに(データを0バイト読み出して)終
了してしまったようです。
従って、アプリケーション側からは、
/dev/ttymxc2から読み出せるデータは無い
というふうに見えています。
ですが、./read_imx25_uart3_recv_reg.shのログを見ると、
FIFOには受信データが格納されています。
正常な動作をしていれば、この受信データはFIFOから取り出されて
アプリケーション側から読み出し可能な状態になっているはずです。
どこでデータの流れが途切れているのかは、
Linuxカーネルのソースコードとハードウェアの動きを追っていく必要があります。
問題が複雑になってきておりますので、担当の者からご連絡差し上げます。
ご不便おかけして大変申し訳ありませんが、
以上、よろしくお願いいたします。
at_kojiro.yamada
2015年6月3日 16時48分
> ※ソフトのバグも疑ってもおりますが、現在、同じファームで5台動作してお
> り、上記現象の出たArmadilloを別のものと入れ替えたりもしたのですが、
> 同じArmadilloでしか、現象が発生しておりません。
念のため、現象が「再現するArmadillo」 と 「再現しないArmadillo」で、
それぞれに書き込まれているイメージ(bootloader, kernel, userland)が
同じかどうか確認していただけないでしょうか?
確認の手順については以下が参考になります。
https://users.atmark-techno.com/blog/53/982
> また、オシロスコープ等で確認する場合、
> どこをあたれば、どこまでデータが来ているかなど確認することが可能でしょ
> うか？
CON9 3pin/5pinはi.MX25に直結されているため、
オシロスコープではi.MX25に信号が届くところまでしか確認できません。
まずは、問題発生時に
カーネル内でデータを受信できているかどうか確認していただけないでしょうか?
UART3の受信データをログに出力するためのパッチを添付いたします。
以下のようにパッチを当ててビルドしたカーネルを使用すると、
UART3がデータを受信するたびに、コンソールに受信データが16進数で出力されます。