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.
-
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
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... -
Well this thread appears to be going nowhere fast, so I'll just keep reporting various things (likely related to a ~focused source problem) that are behaving oddly.
--Found today: Using a pretty simple program to test NeoPixel strips via regular Core - so needing something with non-I2C Ports again. I found that with at least one of my GO-Bases, LCD functions fail. The NeoPx strip works as set in the program, but with just a normal fillscreen cmd, the LCD remains blank.
(As before, using a different base or no base makes everything fully functional again)It actually does the same thing with the Fire, too.
With this particular issue, it's seeming like there may actually be a defect in the GoBase; if not, I'm probably working with something outdated / bad version. That will take some disassembly to figure out.And to clarify, both GoBases were checked for the WiFi malfunction and failed. (i.e. A defective GoBase is not likely causing the WiFi connection issues.)
I'm thinking I'm going to have to eventually eliminate GoBases as a viable hardware option, just to get ports. If anyone knows of a good source of 0.1" to Standard Grove Ports (or something similar - hopefully at right-angle), I could just get those on a Proto module and be done with this mess.
-
@kindly_atlas Ok so this does look like like an issue with the bases you received. Pease contact support@m5stack.com and let them know directly as you have but so much work into diagnosing the issues.
Again, I have the M5Go with the GoBase and do not have any issues.
M5Stack produce the connectors mounted on pcbs here Grove connectors
But sourcing the connections on their own is seriously difficult. -
@ajb2k3
Thanks for the Grove Port link- If I can't find them anywhere else fairly easily, I'll try and get those to work on a Proto....and probably make several similar modules.I agree that one GoBase is likely partially defective - causing WiFi and LCD blackout. [Whereas the other GoBase doesn't interfere - if programs don't involve WiFi.]
+++++
I should note again that I don't own any M5Go s. The above issues (mainly focusing on the WiFi problem) involve the Core [black] and Fire [red]. So, unless you're stating that the GoBase only works correctly with the M5Go, knowing that the M5Go and the GoBase work together doesn't add any info to finding out what the problem is. -
I can confirm experiencing the same issue on two units purchased in separate orders in September - one fire and one M5Go kit. Same experience - removing the bases resolved the wifi connectivity issues.
-
Thanks @alextil
I'm glad I haven't (completely) lost my mind.
I haven't had any progress with this issue besides creating a workaround with a Proto and some Grove ports- assembling a sort of..."Port Board." It certainly isn't pretty, but here's a pic for fun:
It's 2 "Port B"s - to accommodate devices that want GP26, GP36, or BOTH. And a simple male header to Serial2. (16/17)
I've had some thoughts on other things to try (mostly in configuration or digging deeper into M5 and ESP32 libraries), but have been busy with another project that requires much smaller hardware. If you (or anyone) find something that in any way changes this functionality, please post.
All info helps.-Atlas
