mitsuyuki_noto
2022年4月1日 19時49分
貴社 山本様とやり取りさせて頂いた者です。
先日はご対応頂き、ありがとうございます。
別の基板にも同じ環境を構築させようと、アップデートを試みたのですが、
認証不一致とのエラーで書き換えできない、という現象が発生しています。(もともとの環境は動きました。出来ないのは自分の環境です)
認証不一致を解決させる手段を教えて頂いたにも関わらず、です。
またUSBメモリを使用してアップデートさせるのですが、自動アップデートも走りません。
お忙しい中大変恐縮ですが、心当たりは無いでしょうか？
自分の環境を構築することになった理由は、客先で開発しているアプリの動作に不具合が生じていて、
その調査協力のためになります。
使用したファイルを添付しようとしたら、.swu, sw-versions, swupdate.pemファイルは添付出来ませんでしたので、要望有れば山本様経由で送付させて頂きます。
以上、宜しくお願い致します。
コメント
mitsuyuki_noto
mitsuyuki_noto
mitsuyuki_noto
その後ですが、swupdate.pemファイルの不要部を削除してのアップデートを試みましたが、同じエラーとなりました。
そもそもUSB挿入時に自動アップデートが掛からないので、その時点で他にも問題が有るのかも知れません。
自動アップデートが掛からないのは、認証とは別の問題ですか？
貴社からの回答では、USBのルートに置いた場合は特に操作を必要とせずに自動実行・・・との回答でした。
以上です。
> > 松本様 コメント頂きありがとうございます。
> > コメント頂いた内容を試してみます。 SDブートでの初期化は最終手段で考えます。
> > 進展がありましたら、また書き込み致します。
> >
> > 以上です。
at_shinya.matsumoto
認証に問題がある場合は自動アップデートが失敗します。
その場合には/var/log/messageに下記”Signature verification failed”のエラーが出ます。
# tail /var/log/message
Apr 4 16:39:51 armadillo user.info swupdate: START Software Update started !
Apr 4 16:39:51 armadillo user.err swupdate: FAILURE ERROR : Signature verification failed
Apr 4 16:39:51 armadillo user.err swupdate: FAILURE ERROR : Compatible SW not found
Apr 4 16:39:51 armadillo user.err swupdate: FATAL_FAILURE Image invalid or corrupted. Not installing ...
Apr 4 16:39:51 armadillo user.info swupdate: IDLE Waiting for requests...
既にinitial_updateが済んでおり、不要なinitial_setup部分を消している場合、残る可能性としては
アップデート用のswuイメージ(*.swu)を作った環境の鍵(ATDE：mkswu/swupdate.pem)と
G4内部の鍵(/etc/swupdate.pem)で一致する鍵が無い為、アップデートが出来ないという状況
と考えられます。
そこで、G4に鍵を追加する方法として、下記を実施頂けないでしょうか？
①swuイメージを作成した環境の鍵(ATDE：mkswu/swupdate.pem)を入手する
②G4の/etc/swupdate.pemに、上記①の鍵を元の鍵に追加する。
③persist_file /etc/swupdate.pem を実行し、永続化する
以上で、アップデートが出来るようになると思います。
mitsuyuki_noto
松本様、サポート頂きありがとうございます。
お陰様でご指摘通り、mkswu配下のswupdate.pemの中を追記したところ、期待通り動作したことをお伝えします。
(以下①～③を実施)
お客様作成のアプリが動かない調査に入れるようになったこと、大変感謝致します。
また何かありましたら、宜しくお願い致します。
> そこで、G4に鍵を追加する方法として、下記を実施頂けないでしょうか？
> ①swuイメージを作成した環境の鍵(ATDE：mkswu/swupdate.pem)を入手する
> ②G4の/etc/swupdate.pemに、上記①の鍵を元の鍵に追加する。
> ③persist_file /etc/swupdate.pem を実行し、永続化する
>
> 以上で、アップデートが出来るようになると思います。
>
mitsuyuki_noto
お客様アプリとの不具合現象確認で、教えて欲しい事が有ります。
内容としてはGPIO制御ですが、RS485通信制御を実装するため、貴社にGPIO端子制御のパッチを作成頂きましたが、
例えばA→Bへの通信は出来る物の、B→Aへの通信が出来ない現象が出ていて、この時の波形を確認すると送信終了後にDE信号が一旦立ち下がったのち、立ち上がって送信状態になる(およそ20ms後に再度立ち上がる)現象が見えています。DE信号は、勝手に立ち上がるものでは無いと思いますが、DE信号を立ち上げるにはどうすれば良いでしょうか？(送信バッファをデータクリアすれば良い？)
| ファイル | ファイルの説明 |
|---|---|
| 20220405_TP実行時波形.pdf | B→A側通信時波形、DE立下り 約20ms後に再度立ち上がっていてデータ受信できず。 |
mitsuyuki_noto
at_mizo
mitsuyuki_noto
お世話になっております。
RS485⇒USBおよびUSB⇒RS485の送信側の処理はどちらも下記の様に行っており、
送信バッファにデータは残らない認識です。
①送信側シリアルポートをオープン
②データ送信 (Serial.write())
③送信バッファをフラッシュ (Serial.flush())
④送信側シリアルポートをクローズ
上記は弊社開発の基板検査用として実装予定のアプリになり、我々とは別の部隊が開発を担当しております。
> 溝渕です。
>
> アプリケーションはどのような制御を行っているでしょうか?
>
> 例えば、独自アプリケーションを利用せずに、
>
>
> [armadillo]# echo string > /dev/ttymxcX
>
>
> のようにした場合も同様の挙動となりますか?
>
> アプリケーションに関しては、ttyの設定にHUPCLを追加していたり、ハードフロー(RTS)の制御を行っている場合はDE信号が意図せずに動くように見えるかもしれません。
> # DEは、UART_RTSとして実装されています。
at_mizo
mitsuyuki_noto
at_mizo
mitsuyuki_noto
お世話になっております。
早急なご回答、ありがとうございます。
内容は理解致しました。 ただアプリ側ではGPIO側の制御は担当していないので、DE信号制御についてはi.mx側によるものと思っています。
> 意図的にttyの設定やハードウェアフローの制御を行っていない場合、ピンの状態変化が生じるのはシリアルポートのクローズ時ではないかと推測した為です。
> 溝渕です。
>
> > 下記の意図を教えて頂けないでしょうか？
> >
> > > 「④送信側シリアルポートをクローズ」を行なわずに、アプリケーションで無限ループすると、DEがassertされないかご確認いただけますか?
> > 我々とは違う部隊と言いましたが、会社自体も違うので直ぐにはレスポンスできないかもしれませんが、確認致します。
>
> 意図的にttyの設定やハードウェアフローの制御を行っていない場合、ピンの状態変化が生じるのはシリアルポートのクローズ時ではないかと推測した為です。
>
at_mizo
mitsuyuki_noto
1点気になりました。
>> DEをassertしているのではないか
ポートクローズ後 とするとdeassartではないですか？
アクティブローなら、ハイに という意味です。弊社開発基板ではDE信号はアクティブハイなので、ローに遷移する。
> 溝渕です。
>
> > 内容は理解致しました。 ただアプリ側ではGPIO側の制御は担当していないので、DE信号制御についてはi.mx側によるものと思っています。
>
> 上記ご認識で合っています。アプリで制御していないと伺いましたので、close時にi.mx側(LinuxカーネルのUARTドライバ)でDEをassertしているのではないかと推測しました。
>
at_ohsawa
> 1点気になりました。
> >> DEをassertしているのではないか
> ポートクローズ後 とするとdeassartではないですか？
> アクティブローなら、ハイに という意味です。弊社開発基板ではDE信号はアクティブハイなので、ローに遷移する。
そうですね。1回目の返答で溝渕が書いているとおり
「アプリケーションで無限ループすると、DEがassertされないかご確認いただけますか?」
の反対の状態を説明しているだけ、なのでcloseするとdeassertされる想定です。
(ポートというか、ユーザープロセスからttyのデバイスファイルをclose()するとデバイスドライバがdeassertします)
とにかく、想像で話しても仕方ないので試してみるといいですよ。
mitsuyuki_noto
返信が遅くなりました。
結果を言いますと、ポートクローズを止めても変化はありませんでした。
検査用のアプリをクローズする(止める)と、連動してDEが立ち下がる結果になりました。
この現象については、弊社関係者と打合せ致します。
取り急ぎ、ご連絡まで。
> > 1点気になりました。
> > >> DEをassertしているのではないか
> > ポートクローズ後 とするとdeassartではないですか？
> > アクティブローなら、ハイに という意味です。弊社開発基板ではDE信号はアクティブハイなので、ローに遷移する。
>
> そうですね。1回目の返答で溝渕が書いているとおり
> 「アプリケーションで無限ループすると、DEがassertされないかご確認いただけますか?」
> の反対の状態を説明しているだけ、なのでcloseするとdeassertされる想定です。
> (ポートというか、ユーザープロセスからttyのデバイスファイルをclose()するとデバイスドライバがdeassertします)
>
> とにかく、想像で話しても仕方ないので試してみるといいですよ。
at_shinya.koga
アットマークテクノの古賀です。
mitsuyuki_notoさん：
>返信が遅くなりました。
>結果を言いますと、ポートクローズを止めても変化はありませんでした。
>
>検査用のアプリをクローズする(止める)と、連動してDEが立ち下がる結果になりました。
>この現象については、弊社関係者と打合せ致します。
>取り急ぎ、ご連絡まで。
…
>>(ポートというか、ユーザープロセスからttyのデバイスファイルをclose()するとデバイスドライバがdeassertします)
二点確認させて下さい。
mitsuyuki_notoさん（2022年4月5日 10時31分）：
> 内容としてはGPIO制御ですが、RS485通信制御を実装するため、貴社にGPIO端子制御のパッチを作成頂きましたが、
> 例えばA→Bへの通信は出来る物の、B→Aへの通信が出来ない現象が出ていて、この時の波形を確認すると送信終了後にDE信号が一旦立ち下がったのち、立ち上がって送信状態になる(およそ20ms後に再度立ち上がる)現象が見えています。
(1) 「送信終了」時にポートをクローズせず、オープンしたまま、次のデータ送信を実行する、という動作にした場合は、DE が立ち下がる症状は起きなくなったでしょうか？
(2) アプリケーションをクローズする（終了）しない限り、DE が立ち下がる現象は起きないでしょうか？
アプリケーションを終了した場合、アプリケーション（プロセス）終了時に、プロセスが使用していたリソースを OS が解放する動作の一環として、ポートがクローズされると思いますので、アプリケーションからポートをクローズするのと同じことが起きるでしょう。ので、ポートクローズ時に DE が立ち下がるのであれば、アプリケーションがポートをクローズしなくても、アプリケーション終了時に DE が立ち下がるのは自然なことだと思います。
mitsuyuki_noto
能戸です。
お世話になっております。
下記回答致します。
> (1) 「送信終了」時にポートをクローズせず、オープンしたまま、次のデータ送信を実行する、という動作にした場合は、DE が立ち下がる症状は起きなくなったでしょうか？
→これについては、RS485通信 本件とは別要因の状況が見えてきました。 USB側とRS485との間にUSB-RS485変換ケーブルがあって、拡張基板側でループバックさせるようにしているのですが、RS485からの出力は問題無くUSBからの出力時にRS485で受信エラーになるのですが、USB出力時になぜかDEをアクティブに(立ち上げ)する動作をしていることが分かりました。これは検査用アプリを開発しているソフトチームに問い合わせています。
> (2) アプリケーションをクローズする（終了）しない限り、DE が立ち下がる現象は起きないでしょうか？
→つまりは、一度RS485送信をしたらアプリクローズまでたち下がらないのか？との質問でしょうか？
今見ている現象としては、それは有りませんでした。(DEは、RS485出力時は貴社からご提供を受けたパッチで希望通りの動作になっています)
> アプリケーションを終了した場合、アプリケーション（プロセス）終了時に、プロセスが使用していたリソースを OS が解放する動作の一環として、ポートがクローズされると思いますので、アプリケーションからポートをクローズするのと同じことが起きるでしょう。ので、ポートクローズ時に DE が立ち下がるのであれば、アプリケーションがポートをクローズしなくても、アプリケーション終了時に DE が立ち下がるのは自然なことだと思います。
at_shinya.matsumoto
2022年4月1日 20時54分
アットマークテクノの松本です。
G4を初期化しても良い場合は、SDブートで初期化し再度initial_updateから実施する方法が簡単です。
SDブートで鍵情報もリセットされます。
mkswu initial_setup.desc update.desc で署名とアップデートを一括で実行も可能です。
◆インストールディスク作成～インストール
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
原因につきましては、initial_setupが完了している状態で鍵情報がマッチしない場合、
下記に分類できると思います。
鍵情報は下記に有ります。
G4 ：/etc/swupdate.pem
ATDE等：mkswu/swupdate.pem
①initial_setupが完了している（＝鍵が一致する）が、エラーになる場合
考えられる理由：update.descの中にinitial_setupの設定が残っている
対応策：initial_setupの部分を削除し、アップデート
②他の鍵情報でinitial_setupが完了している（＝鍵が一致しない）
対応策：上記SDブートで初期化頂く（確実）
もしくは、G4のswupdate.pemにmkswu.pemの鍵情報を追記し、
persist_file swupdate.pemを実行し、アップデート
(後者は試せていません）
アップデートする条件は、G4の鍵情報にmkswuの鍵情報が追記されている事と、アップデート
しようとしているdescファイルのバージョンが、/etc/sw-versionsに記載されているバージョンより
新しい事(例：１→２）になります。（署名エラーですので後者は今回は関係ないと思います）