bakueikozo / buildroot_am3352_aki

Other
24 stars 6 forks source link

WI-SUNモジュールと疎通できない? #1

Open keroro9 opened 1 year ago

keroro9 commented 1 year ago

素晴らしいものをありがとうございます。帰宅し即試した次第です。WSL2でコンパイルしていましたが、

mv: cannot move '/home/<username>/buildroot_am3352_aki/output/build/toolchain-external-arm-arm-2021.07/arm-none-linux-gnueabihf' to '/home/<username>/buildroot_am3352_aki/output/host/opt/ext-toolchain/arm-none-linux-gnueabihf': Permission denied

でコンパイル失敗していたため、ひとまずコンパイル済みイメージをダウンロードさせていただき試させていただいております。

さて本題は掲題の通りなのですが、WI-SUNモジュールと疎通できず詰まっておりまして、失礼を承知で書き込みする次第です。

環境

操作

minicom -b 115200 -D /dev/ttyS1
SKSREG S1 #プロンプトには何も帰ってきません

image

この状態でエコーバックがなく、モジュールから何も帰ってこない状態です。 ハードウエアフローコントロールが悪さしているかと思い、 https://qiita.com/baggio/items/3db759da67c0123e993e を参照し、

F - Hardware Flow Control : No

とし、ハードウエアフローコントロールを切ってみましたが、状態は変わりませんでした。

次に、モジュールを取り外し、pin7のリセット信号をオシロスコープで観測したところ、3.3v出ているようでした。また、pin11のUART_TX(モジュールから見てRX)もきちんと何か出ているようで、オシロスコープでシングルトリガをかけ何かキーを押すと、UARTの波形らしきものが出ます。ロジアナはあるのですが、プロービング用の配線がしんどくロジアナでは信号見れていません。

これらより、HW的にはリセット・UARTともに扱えていると思うのですが、いったい何がおかしいのかといったところです。

Beaglebone black用のdebianを焼いたFW予備am3352_akiがありましたので、内臓のFlashを飛ばした後、aki3352_buildboot.img経由で起動し同様に試しましたが、結果は同様でした。(説明の都合前後していますが、順番としてはこちらを先に行いました)

不勉強で大変恐縮ですが、どなたかお知恵を貸していただけませんでしょうか! また、aki3352_buildboot.imgでWI-SUNモジュールが動いたよ~という方いらっしゃいましたら、教えていただけませんか? 普段issueを立てることがほぼありませんので、お作法間違っておりましたらすみません。よろしくお願いいたします。

bakueikozo commented 1 year ago

ご試用ありがとうございます。 あれ???何か確認漏れか???と思って慌てて手元でやってみたのですが、一応ちゃんと出る… と思ったところ、minicom/screenを何度か起動したり、本体を再起動したりすると結構な確率で応答がないことがあることがわかりました。全然気づかなかったです。 ちゃんと出るときは出るので、何かしらの接続エラーがあるのか、状態不定なものが悪さをしているかもしれません。 もう少し調べてみます。

bakueikozo commented 1 year ago

途中経過ですが、応答がないように見えた時に、Wi-SUNからはエコーバックされていて、コネクタまでは信号が来ているようです。

bakueikozo commented 1 year ago

あ、そこまでも見えてるのか。なんでだー

bakueikozo commented 1 year ago

あれこれ試してみましたが、再現しなくなってしまいました。引き続き様子は見てみようと思います。 補足ですが、基板裏のCN20のWi-SUNシルク側二本、それぞれTX/RXが出ているようです。プローブするならここがいいと思います。 https://twitter.com/bakueikozo/status/1638948023207366656?s=20

keroro9 commented 1 year ago

早速お返事が付いていてびっくりです!。解析模様をリアタイで見ていたので、お気持ちに水を差すような投稿になってないか心配でした。いろいろと追加情報を頂きありがとうございます。

こちらでも少し見てみましたが、まだうまくいってはいません。

機材等

手順 20230324

  1. まず、いただいた情報のとおりプローブ線を引いてます。 image_6487327 ※映りが微妙ですが、一応目視の限りは半田ブリッジなどはなさそうです。

  2. 次に、予備実験として、USB-UARTケーブルをロジアナのプローブにつないでみました。UARTのTXをトリガにしましたが、かかるタイミングが微妙に悪いせいかデコードはできませんでした。この辺コツがあった気がするのですが忘れてしまい。確かトリガは別にGPIOで出さないとうまくデバッグできなかった記憶があります。

  3. ロジアナでとりあえず信号見えることはわかりましたので、改めて引っ張ったCN20から、WI-SUNモジュールに行っているUART1(ttyS1)を観測しました。送信したキーはsです。

UART_Settings

  1. やはりエコーバックはありませんでした。また、この状態でSKSREG S1を入力しましたがやはり応答はありませんでした。

  2. さらに、GPIO53をOFF→ONしましたが状況は変わらず、再起動を複数回しても変わらない、という状況です。

手順が間違っていたり、minicomの設定に誤りがあるのではないかと思ったりetc...いわゆるおま環も疑っております。品切れ直前滑り込みで追加購入が間に合ったので、届けば別の基盤で試してみようと思います。

また何かわかれば書き込みさせていただきます!他の皆様の情報収集も行いつつ...。

keroro9 commented 1 year ago

日記投稿すいません。更に試行中です。gitからプロジェクトをcloneしてきてmake。昨日WSL上で失敗したので権限の問題かと思い、sudoを付け実行しました。

$ make akiduki_am3352_defconfig

$ sudo make -j 110 #48coreくらいあるCPUが2個乗ってるのでスレッド多めです

イメージは一応出来上がったので、sdcard.imgをWin32Diskimager renewalで焼きこみ起動させたところ、

does_not_boot

で停止してしまうので、ビルドが生焼けなのだと思われます。(buildrootは一般権限で実行するとどこかで読んだ気がするので、またあとでやってみようと思います。)

いったん配布いただいていたaki3352_buildroot.imgを用いて再度Bootさせ、別基盤で

minicom -b 115200 -D /dev/ttyS1
SKSREG S1

を実行しましたがダメでした。

2023/3/24 追記

image

昼間はロジアナの調子が悪かったのですが、PC変えてトリガ条件変えたところ安定しました。上の書き込み、失礼しました。

bakueikozo commented 1 year ago

うーんなんでなんでしょう こっちでもなんか調子悪かった気がするんですが、今日は全くエラーも出ず、 通信中にモジュールを抜き差しするぐらいのことをしても問題なく動いているんですよね…

生焼けのイメージ、もし可能なら共有してもらえませんか。どんな感じになっているのか気になるので。

bakueikozo commented 1 year ago

あ、もしやと思って手元でビルドしなおしてみたら同じような起動画面になりました。こっちの設定ミスっぽいです。

keroro9 commented 1 year ago

ありがとうございます。謎ですね。私がシロウトなので、変なことをやっているのかもしれないです。

Eikpyrmir commented 1 year ago

横から失礼します。 自分も最初にMicroSDからブートした時に、Wi-Sunと疎通できなかったのですが、 一度、BeagleBoardのAM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasherで、 eMMCに書き込みをして、色々やった後に、U-BootでeMMCをeraseしてから、 (eMMCブートになってMicroSDからブートしなかったため) 再度MicroSDカードからブートしたら、Wi-Sunと通信できるようになってました。 直接関係ないかもしれませんが、一応、情報としてお伝えしておきます。

keroro9 commented 1 year ago

貴重な情報ありがとうございます。差し支えなければ、U-Boot上からEraceされた手順を教えていただくことは可能でしょうか?

私のErace方法がかなり乱暴で、bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.imgからSDをBootして、自動的にeMMCがEraceされるところまでスクリプトを進めて電源を切るというやり方でやっています。

=> mmc dev 1
=> mmc erase 0 100000

この辺でしょうか?

keroro9 commented 1 year ago

追記です。

mmc dev 1

//この間にいろいろやるがusageが出てきてしまう。

//あるタイミングで消せるようになった
=> mmc erase 100 2800

MMC erase: dev # 1, block # 256, count 10240 ...
=> mmc erase 0 2800

MMC erase: dev # 1, block # 0, count 10240 ... 10240 blocks erased: OK

で一応消去できたようでした。お騒がせしました

misodengaku commented 1 year ago

私も同じ問題に悩まされていたのですが、Wi-SUNモジュールへのコネクタ5ピンを絶縁してみたところ疎通が取れるようになりました。動くことを確認した後テープを剥がすとまたエコーバックもない状態に戻ったのでWi-SUNモジュールの5ピンが悪さをしている線が濃厚ではないかと考えています。

NZ6_3110

MB-RL7023-11/DSS ユーザーズ・マニュアル では未接続にせよとなっているところ、何か謎基板上で余計な処理がされていることでWi-SUNモジュールが誤動作しているのではないかと思いますが、謎基板上のパターンを追うのが困難なためその先は調べていません。

image

kanpapa commented 1 year ago

私も同様な症状になっていまして、Wi−SUNモジュールと通信できるときは問題なくできるのですが、急に何も反応がない状態になったら無反応のままとなってしまい、なかなか元に戻らずです。Yoctoでbuildしたものも似たような状態でして、いろいろ試しているところです。Wi-SUNモジュールの5ピンの情報を参考にしてまた調べてみます。

keroro9 commented 1 year ago

皆様素晴らしい情報ありがとうございます!ピンマスク法、私も試してみます。 こちらでいろいろと試していると、モジュールを付けたまま電源を入れ、いったん取り外し再度装着すると100%疎通が取れることがわかりました。ですので、謎基盤の電源ON時のピン初期化などに何か癖があるのかと思っていました。

+3.3vをGPIO(LED)につないで意図的にON-OFFできるように変更し、モジュールを完全にリセットできないかと考えていたところです(ただ、0.5mmピッチのピンをはがす機材がないですが)。ですので、ピンマスク法はブレイクスルーかもと思っています。

(余談) https://qiita.com/chibiegg/items/4b1b70a5ba09c4a52a12?utm_campaign=post_article&utm_medium=twitter&utm_source=twitter_share

に、謎基盤debian化の紹介もありましたので、ピンマスク法で安定すれば、IoT箱として本格的に使えそうな気がします。

bakueikozo commented 1 year ago

大変有効な情報ありがとうございます。 早速配線を辿り、該当ピン GPIO 0[7]をHIGHにするようにしてみたところ、応答が必ず帰ってくるようになることを確認しました。 こちらのピンは起動直後Lなので、 cd /sys/class/gpio && echo 7 > export && echo out > gpio7/direction && echo 1 > gpio7/value してみました。 ただし、この後、戻しても応答は帰ってきています。 いずれにせよ、HIGH状態が正しいと思いますので、各distのdstで定義してやれば動く気がします。

kanpapa commented 1 year ago

早速dtsに組み込みました。今のところ私の環境(Yocto版ですが)では安定して動いています。ありがとうございました。 image

keroro9 commented 1 year ago

早速成功されているようで何よりです!(組み込み界隈の皆様すごいです...) buildroot_am3352_akiを修正するとすれば、 am335x-akiduki-junk.dts に

        usr_3_led {
            label = "led1";
            gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
            default-state = "off";
        };
          //add
        usr_wisun_pin5 {
            label = "wisun_pin5";
            gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
            default-state = "off";
        };

としてやればよいのでしょうか?

kanpapa commented 1 year ago

Highにしないといけないので、こうでしょうか。

        usr_wisun_pin5 {
            label = "wisun_pin5";
            gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
            default-state = "on";
        };
keroro9 commented 1 year ago

ご指摘ありがとうございます!! 試すのが楽しみでなりません。

仕事のほうが燃えているので、週末になりますが試してみます。

chibiegg commented 1 year ago

理想的には未接続を再現するために High-Z にするのが良いかなと思ったので、以下のように GPIO7 を入力にしてみたら動くようになった個体がでてきました。

echo 0 > /sys/class/leds/wisun_reset/brightness
echo 7 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio7/direction
echo 1 > /sys/class/leds/wisun_reset/brightness

ただ、全ての個体で動作するところまでは確認できませんでした。

ところが、プルアップ付きの入力にするとうまく動くので、以下の通りしてあげると動きました。

echo 0 > /sys/class/leds/wisun_reset/brightness
echo 7 > /sys/class/gpio/export
echo high > /sys/class/gpio/gpio7/direction
echo 1 > /sys/class/leds/wisun_reset/brightness

デバイスツリーでデフォルトのプルアップ入力状態を作るにはどうしたらいいんでしょう...

chibiegg commented 1 year ago

Debian化の記事にもワークアラウンドを追加しましたが、以下のように rc.local で起動時に操作すれば安定して動作することを確認しました。

# Wi-SUNモジュールの安定動作対応
cat - << EOS > /etc/rc.local
#!/bin/sh

echo 0 > /sys/class/leds/wisun_reset/brightness
echo 7 > /sys/class/gpio/export
echo high > /sys/class/gpio/gpio7/direction
echo 1 > /sys/class/leds/wisun_reset/brightness

exit 0
EOS

chmod a+x /etc/rc.local
bakueikozo commented 1 year ago

Hi-Zが本当はいいんですが、実は添付の画像のようにGPIOとWiSUNモジュールの間にオープンドレインのバッファが入っていて image この回路だと、SoC側をいじってもHi-Zにならないんですよ。 CMOS入力のロジック回路は、Hi-Zの入力が本来はNGで、VCCかGNDに吊る必要があるんですが、 そのためのR88が省略されているので、SoC側で必ず電位を決めてやらないと出力が不安定になってしまいます。 なので、本来はU16のゲートから切り離されているのが正解なんですが…設計・実装・リファクタのどれかでミスってますねこれ。

chibiegg commented 1 year ago

そういうことですか! それならプルアップで動くことや、GPIOを出力にしてしまっても良いことに納得が行きます。