M5Stack Core2がリスタートできない。

最近使っていなかったが、考えれば手元にあるM5Stick Cは、ともかくM5Stack Core2はモータとステアリング操作に、I2C、GPSとの通信にUART、RTKにWi-Fi、アピールに音、操作関係にはタッチパネル。

ちょっとパフォーマンスの心配はあるが、サーボをI2Cでやってしまえば可能性ありかと。

本当はパフォーマンスを考慮してRaspberry pi PICO Wを使いたかったんですが、まだ技適前。自分で研究用で申請してしまうのもありだが、そのものが手に入らない。 Arduino IDEでアプリ組めるし。 と思っていたが、また次回のお遊び用に。

さて、M5StackCore2のリハビリを兼ねて数字を表示するスケッチを。

#include <M5Core2.h>

static int i;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);  //USB to PC
  delay(100);
  M5.begin(); 
  M5.Lcd.fillScreen(BLACK);
  M5.Lcd.setTextColor(GREEN , BLACK);
  M5.Lcd.setTextSize(2);
  M5.Lcd.println("M9 Started");
  Serial.println("M9 Started");
}

void loop() {
  i = i + 1;
  M5.Lcd.setCursor(0,15);
  M5.Lcd.println(i);
  M5.Lcd.println("123456");
  Serial.println(i);
  delay(500);
}

あれ? うまくいくときもあるが、再書き込みで止まったり、リスタートボタンの横のLEDが消えていたり、動作がおかしい。 リスタートボタンをおしてもウンスンではないか。。。

もしや、ESP32やUnoで時々苦しめられたRSTの信号不安定か?

ググってみると。 Core2においては、同現象に悩まされている人もいるが、それほど多くはない。

過去のセオリー通りにRSTとGND間にコンデンサをつけている人も確かにいる。

幸いCore2には端子もある。。。 おもちゃオシロで見てみるべきか。。。

こんな時にはリビング行ったり、冷蔵庫空けたり、、、、そういえば、Fall Guysが無料になっているんですよね。 なんとなく、Fall Guysの名前が覚えられなくて、Whole Foodsが頭の中に出てくることこの頃。

ってなことを考えながら、再度PCの前に。。。 Delayを増やしたり、カーソル処理を外したり。。。 あれ? ダウンロードするときに Time Out起こすことも、ますますCore2がひねくれている。

こうゆうときは、一度工場出荷へ。 EasyLoader_M5Core2_FactoryTest.exe を使って、最初のアプリをロード。 あれ? 動くじゃん。 リスタートも何度やっても問題ない。 これのアプリ部分だけ入れ替えたいなぁ。。。

ん? 

OSが原因か? ボード情報を取得してみると、対象外? んん? M5StackのCore2のボードと設定しているが、中身がこっそり変わっていたか??? ファームのスタイルが変わっていてIDEと一致していなかったのかも。

さっそく、ボードマネージャでM5Stackを検索。 インストールは1.0.6 最新は2.0.3。 これかぁ。。

最新に上げて、ダウンロードして事なきを得た。 コンパイルが長くてたまらん。 PCの性能もあるが、何とかしてくれ!!! 昔もコンパイル間に仮眠をとっていた時代が懐かしい。 これが原因だったのね。

すると、これまでESP32でトラブっていたのもこれが原因だったのでは??? と疑ってしまう。

動作確認して良好を確かめ一安心。 念のためにライブラリのM5Core2も0.1.2から0.1.4に挙げておいた。

再度動作確認して問題のないことを再確認してComplete!

代品の入手

故障を断定した後は、代品をどうするかという話である。

いっそのこと既製品のLoRa Gatewayを購入してそのサービスを体験しようという考えもあり、SORACOMのGatewayにはかなり興味を持っていた。
しかし、本当にHATの故障を証明したいのと、まずは素材レベルでいろいろと知見を確保したいので結局HATを購入することとした。

新しいHATが到着後、、おそるおそるPiに接続して動作確認すると、下記のように問題なく立ち上がった。

pi@raspberrypi:~/dual_chan_pkt_fwd $ ./dual_chan_pkt_fwd
server: .address = router.jp.thethings.network; .port = 1700; .enable = 1
server: .address = router.as2.thethings.network; .port = 1700; .enable = 0
Gateway Configuration
XXXXXXXXXXXXXXXXXXX ← ここは自主規制
testing IoT
Latitude=0.00000000
Longitude=0.00000000
Altitude=10
Interface: wlan0
Trying to detect module CE0 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE0, starting.
Trying to detect module CE1 with NSS=6 DIO0=7 Reset=3 Led1=unused
SX1276 detected on CE1, starting.
Gateway ID: xx:xx:xx:ff:ff:xx:xx:xx ← ここは自主規制
Listening at SF10 on 923.200000 Mhz.
Listening at SF10 on 923.200000 Mhz.
stat update: 2020-05-03 00:36:27 GMT no packet received yet
stat update: 2020-05-03 00:36:57 GMT no packet received yet

そのた、ここ似たどつくまでに試したものとしては、

Single_chan_pkt_fwdもWebで見つけて試してみた。動作を確認するためにはプログラムがシンプルで大いに助かった。

SPIの調査

(ちょっと効果的だったあがき1)
怪しいのはSPI。でもSPIの機器はちょっと考えてみたのだが、手元にはなさそう。
そこで、考えたのが、とりあえず自分で折り返してPi側の健全性を確認する。
まずは、SPI関連のモジュールを確認した。

参考にさせてもらったのは下記のページ。
https://tomosoft.jp/design/?p=5428

これで、動作確認をしてみると、Piのみで配線を折り返してLoopbackを実施すると問題ない。試しにLoopBackの配線を外した結果と。HATを接続した場合は同じ結果となる。
ここまで、証拠を突きつければおのずと、HATの単品故障と断定した。

SPI機器の動作がうまくいかないときにはおすすめである。

HATが応えない!

(無駄なあがき1)
ソース( dual_chan_pkt_fwd.cpp )を見てみると、、、
”Unrecognized transceiver” が出るときは、プログラム終了? まぁ、認識できないんだからそうあるべきだが、この”Success”は SPI デバイスからの戻り値が予想外ということだった。

この手のトラブルは日常茶飯事なので、さっそく幾つが戻ってくるかをDebugメッセージを追加。 すると、”0”が戻ってきていた。

SPIが調子悪いと思いつつ、Pin配置やほかのプログラムも確認。 まぁ問題はなさそう。

(無駄なあがき2)
そういえば、このPiでSPIを使ったことがない。 手持ちにあるほかのRaspberry Piを持ってきて、やっても結果は変わらず。 結局もとのPi Zeroで継続調査することとした。

試行錯誤すること1日 、気が付いたら赤いLEDがついている。 「???」 よく見たら電源のLEDである。 電源不足だったというオチでした。
そこで、容量の大きい電源に入れ替え、再実験。 それでも結果は同じ。

”Unrecognized transceiver” が出る。 
電源に気が付いたのは良いが、これまでのは無駄なあがきだった。。。