WiFi Connection Failure when using "GO" Base / Bottom



  • Hi All,
    Have been using many M5 products for ~a year now, but first time in this forum.
    Only with a recent addition did I find a seemingly inherent problem with the M5GO architecture, and I'm wondering if it's just me, or if anyone knows of a workaround for it.

    I recently received the 'NeoFlash' board and wanted to try out a clock on it- using example code, and an easy ntp time check - obv. requiring WiFi access. The NeoFlash requires that a 'M5GO' base is attached, to utilize the Port B GPIO.

    tl;dr: I found that the code, and then even standard ESP32 WiFi and M5Stack WiFi examples would NOT connect to a provided Wi-Fi network when the GO was attached. I've tried all of these examples on different Cores (Black), including a Fire, and different GO-Bottoms- and they all behave the same.
    e.g.
    WIFI-SSID: [###]
    WIFI-PASSWD: [###]
    Waiting for Wi-Fi Connection...........

    In fact, it sometimes seems that the GO/FIRE Base prevents even the attempt to initialize WiFi, and I just get a blank screen. To back the code (besides the fact that these are Library and Hardware examples), everything initializes and connects happily if no GO Base is attached (i.e. Just on USB Power) or a standard Core "Battery Bottom" is used.

    IDEAS:

    • GO Base H/W Compatibility: The Bottom is meant to only interact with Grey/GO Cores; but seems unlikely because they are sold attached to Fires.
    • GO Base S/W Compatibility: The Bottom is meant only for UIFlow operations, and cannot do WiFi activities via standard (Arduino) coding.
    • Some code characteristic (#include, #define, other setting) must be included to allow interaction with GO Base and WiFi. GO Bottoms all work fine if WiFi isn't involved.
    • ?

    I've seen a couple other threads that address this topic, but none with actual troubleshooting or a resolution. As far as this particular project goes, the only way I believe I can interact with the NeoFlash is to use the standard Bottom, connect Dupont headers to it, convert those to Grove, and have the board plug into that. If you're thinking "That sounds really stupid...", that's why I'm here.

    --Open to any suggestions from people experiencing the problem (for troubleshooting purposes) or anyone that can define / correct what the actual problem is here. (Even if the problem is me)

    Thanks in advance,
    Atlas



  • @kindly_atlas This is really weird. I have an M5Go with the Go Base and wifi works fine.

    The I/O base was designed back for the core and gray and only contains a battery and I/O pins. The Go base came with the M5Go and Fire. it was only down to the fact we complained about availability that the bases are now available separately.


  • M5Stack

    Could you share a sample of the wifi connection code you used please



  • @ajb2k3 This may all be a mix-up in product terminology, so pardon if what I'm saying doesn't make any sense... lol

    I don't have any M5Gos- (the gray/white ones) --only "Core"s (black) and "Fire"s.
    I first obtained an M5Go Base attached to a Fire, like you said, and then purchased another to perhaps use with regular Cores.

    I understand the Go Base was designed for the M5Go initially, but (to confirm) is it fully compatible with regular Cores?

    Otherwise, this WiFi / Base dysfunction also occurs when used with a Fire...



  • @lukasmaximus The code for NeoFlash clock is pretty lengthy- but it is still the example code taken straight from M5 Github.

    To make things simpler, and for testing, I'm also using the "WiFi Setting" example that is in the M5 library. (It behaves the same)

    Since you all have the code, and many have used WiFiSetting fundamentals everywhere, I'll leave that out. Instead, here's the Serial of that program- On a Fire, with an M5Go Base
    Note for the code: it has run already, so WiFi info has already been written to memory
    0_1573243716774_M5wifibug-WiFiSetting_Serial.jpg

    You can see at 47:09.194 that it already knows what the settings are and lists them correctly - but then a Timed Out fail ~30 seconds after not catching anything.
    It starts the webserver for reconfiguration, and on that site, interestingly, (on the dropdown selection provided by "ssidList") no networks are found or selectable. (i.e. It's a blank field)

    At 48:09.698, I removed the M5Go Base while leaving the system plugged in to the PC via USB. That triggered a Reset (as expected), but now without the Base, the system connects to the same network in about a second. (48:10.789 to 48:11.835)

    If you have some other code, or a source of it, to try instead of the examples, I can check that out...



  • --A random new thought--
    I was looking through some example code for unrelated reasons, and I noted that some new stuff has the Power class / utility initialized near the normal M5 Begin. e.g.M5.Power.begin() (With some comments about that statement needing to be there.)

    I'm digging through Power's source files, but am somewhat unfamiliar with the class in general- so I'm not exactly certain of what properties or functions are available within it. (I know it's mostly in charge of interfacing with the I2C power controller on P21/P22- but not the specifics beyond that)

    Considering the Go Base has some different battery properties, AND tosses some extra items onto GPIO/I2C -- could this Connectivity issue perhaps be related to something needing to be set within the Power class, or within "M5.begin()" in general?
    Just a thought...maybe it'll spark an idea...