Open keroro9 opened 1 year ago
ご試用ありがとうございます。 あれ???何か確認漏れか???と思って慌てて手元でやってみたのですが、一応ちゃんと出る… と思ったところ、minicom/screenを何度か起動したり、本体を再起動したりすると結構な確率で応答がないことがあることがわかりました。全然気づかなかったです。 ちゃんと出るときは出るので、何かしらの接続エラーがあるのか、状態不定なものが悪さをしているかもしれません。 もう少し調べてみます。
途中経過ですが、応答がないように見えた時に、Wi-SUNからはエコーバックされていて、コネクタまでは信号が来ているようです。
あ、そこまでも見えてるのか。なんでだー
あれこれ試してみましたが、再現しなくなってしまいました。引き続き様子は見てみようと思います。 補足ですが、基板裏のCN20のWi-SUNシルク側二本、それぞれTX/RXが出ているようです。プローブするならここがいいと思います。 https://twitter.com/bakueikozo/status/1638948023207366656?s=20
早速お返事が付いていてびっくりです!。解析模様をリアタイで見ていたので、お気持ちに水を差すような投稿になってないか心配でした。いろいろと追加情報を頂きありがとうございます。
こちらでも少し見てみましたが、まだうまくいってはいません。
まず、いただいた情報のとおりプローブ線を引いてます。 ※映りが微妙ですが、一応目視の限りは半田ブリッジなどはなさそうです。
次に、予備実験として、USB-UARTケーブルをロジアナのプローブにつないでみました。UARTのTXをトリガにしましたが、かかるタイミングが微妙に悪いせいかデコードはできませんでした。この辺コツがあった気がするのですが忘れてしまい。確かトリガは別にGPIOで出さないとうまくデバッグできなかった記憶があります。
ロジアナでとりあえず信号見えることはわかりましたので、改めて引っ張ったCN20から、WI-SUNモジュールに行っているUART1(ttyS1)を観測しました。送信したキーはsです。
やはりエコーバックはありませんでした。また、この状態でSKSREG S1
を入力しましたがやはり応答はありませんでした。
さらに、GPIO53をOFF→ONしましたが状況は変わらず、再起動を複数回しても変わらない、という状況です。
手順が間違っていたり、minicomの設定に誤りがあるのではないかと思ったりetc...いわゆるおま環も疑っております。品切れ直前滑り込みで追加購入が間に合ったので、届けば別の基盤で試してみようと思います。
また何かわかれば書き込みさせていただきます!他の皆様の情報収集も行いつつ...。
日記投稿すいません。更に試行中です。gitからプロジェクトをcloneしてきてmake。昨日WSL上で失敗したので権限の問題かと思い、sudoを付け実行しました。
$ make akiduki_am3352_defconfig
$ sudo make -j 110 #48coreくらいあるCPUが2個乗ってるのでスレッド多めです
イメージは一応出来上がったので、sdcard.imgをWin32Diskimager renewalで焼きこみ起動させたところ、
で停止してしまうので、ビルドが生焼けなのだと思われます。(buildrootは一般権限で実行するとどこかで読んだ気がするので、またあとでやってみようと思います。)
いったん配布いただいていたaki3352_buildroot.imgを用いて再度Bootさせ、別基盤で
minicom -b 115200 -D /dev/ttyS1
SKSREG S1
を実行しましたがダメでした。
昼間はロジアナの調子が悪かったのですが、PC変えてトリガ条件変えたところ安定しました。上の書き込み、失礼しました。
うーんなんでなんでしょう こっちでもなんか調子悪かった気がするんですが、今日は全くエラーも出ず、 通信中にモジュールを抜き差しするぐらいのことをしても問題なく動いているんですよね…
生焼けのイメージ、もし可能なら共有してもらえませんか。どんな感じになっているのか気になるので。
あ、もしやと思って手元でビルドしなおしてみたら同じような起動画面になりました。こっちの設定ミスっぽいです。
ありがとうございます。謎ですね。私がシロウトなので、変なことをやっているのかもしれないです。
最短コースだと、aki3352_buildroot.imgを焼いてminicom叩けばWI-SUNにアクセスできるはずなので、どこかで要らないことをしているか、環境差分があるのか。
念のためUSB-UARTを同型番予備に変更&電源も変更(RAVPOWERのAC-USBAアダプタ)しましたがダメでした。
オシロの波形も変なノイズが乗っている感じではないので、電源ノイズとかそういうやつではなさそうです。ボードによっても癖があるのかも?
イメージ一応UPしておきます。 https://drive.google.com/file/d/1slIbLq6ugCzM66m95x_p0AGWUsJyRbxZ/view?usp=share_link
横から失礼します。 自分も最初に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と通信できるようになってました。 直接関係ないかもしれませんが、一応、情報としてお伝えしておきます。
貴重な情報ありがとうございます。差し支えなければ、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
この辺でしょうか?
追記です。
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
で一応消去できたようでした。お騒がせしました
私も同じ問題に悩まされていたのですが、Wi-SUNモジュールへのコネクタ5ピンを絶縁してみたところ疎通が取れるようになりました。動くことを確認した後テープを剥がすとまたエコーバックもない状態に戻ったのでWi-SUNモジュールの5ピンが悪さをしている線が濃厚ではないかと考えています。
MB-RL7023-11/DSS ユーザーズ・マニュアル では未接続にせよとなっているところ、何か謎基板上で余計な処理がされていることでWi-SUNモジュールが誤動作しているのではないかと思いますが、謎基板上のパターンを追うのが困難なためその先は調べていません。
私も同様な症状になっていまして、Wi−SUNモジュールと通信できるときは問題なくできるのですが、急に何も反応がない状態になったら無反応のままとなってしまい、なかなか元に戻らずです。Yoctoでbuildしたものも似たような状態でして、いろいろ試しているところです。Wi-SUNモジュールの5ピンの情報を参考にしてまた調べてみます。
皆様素晴らしい情報ありがとうございます!ピンマスク法、私も試してみます。 こちらでいろいろと試していると、モジュールを付けたまま電源を入れ、いったん取り外し再度装着すると100%疎通が取れることがわかりました。ですので、謎基盤の電源ON時のピン初期化などに何か癖があるのかと思っていました。
+3.3vをGPIO(LED)につないで意図的にON-OFFできるように変更し、モジュールを完全にリセットできないかと考えていたところです(ただ、0.5mmピッチのピンをはがす機材がないですが)。ですので、ピンマスク法はブレイクスルーかもと思っています。
に、謎基盤debian化の紹介もありましたので、ピンマスク法で安定すれば、IoT箱として本格的に使えそうな気がします。
大変有効な情報ありがとうございます。 早速配線を辿り、該当ピン GPIO 0[7]をHIGHにするようにしてみたところ、応答が必ず帰ってくるようになることを確認しました。 こちらのピンは起動直後Lなので、 cd /sys/class/gpio && echo 7 > export && echo out > gpio7/direction && echo 1 > gpio7/value してみました。 ただし、この後、戻しても応答は帰ってきています。 いずれにせよ、HIGH状態が正しいと思いますので、各distのdstで定義してやれば動く気がします。
早速dtsに組み込みました。今のところ私の環境(Yocto版ですが)では安定して動いています。ありがとうございました。
早速成功されているようで何よりです!(組み込み界隈の皆様すごいです...) 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";
};
としてやればよいのでしょうか?
Highにしないといけないので、こうでしょうか。
usr_wisun_pin5 {
label = "wisun_pin5";
gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
ご指摘ありがとうございます!! 試すのが楽しみでなりません。
仕事のほうが燃えているので、週末になりますが試してみます。
理想的には未接続を再現するために 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
デバイスツリーでデフォルトのプルアップ入力状態を作るにはどうしたらいいんでしょう...
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
Hi-Zが本当はいいんですが、実は添付の画像のようにGPIOとWiSUNモジュールの間にオープンドレインのバッファが入っていて この回路だと、SoC側をいじってもHi-Zにならないんですよ。 CMOS入力のロジック回路は、Hi-Zの入力が本来はNGで、VCCかGNDに吊る必要があるんですが、 そのためのR88が省略されているので、SoC側で必ず電位を決めてやらないと出力が不安定になってしまいます。 なので、本来はU16のゲートから切り離されているのが正解なんですが…設計・実装・リファクタのどれかでミスってますねこれ。
そういうことですか! それならプルアップで動くことや、GPIOを出力にしてしまっても良いことに納得が行きます。
素晴らしいものをありがとうございます。帰宅し即試した次第です。WSL2でコンパイルしていましたが、
でコンパイル失敗していたため、ひとまずコンパイル済みイメージをダウンロードさせていただき試させていただいております。
さて本題は掲題の通りなのですが、WI-SUNモジュールと疎通できず詰まっておりまして、失礼を承知で書き込みする次第です。
環境
操作
この状態でエコーバックがなく、モジュールから何も帰ってこない状態です。 ハードウエアフローコントロールが悪さしているかと思い、 https://qiita.com/baggio/items/3db759da67c0123e993e を参照し、
とし、ハードウエアフローコントロールを切ってみましたが、状態は変わりませんでした。
次に、モジュールを取り外し、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を立てることがほぼありませんので、お作法間違っておりましたらすみません。よろしくお願いいたします。