beta7 Metro M4 + AirLift

[mikeysklar]

No, luck with beta7 to connect to my WiFi using M4 Metro. Never get to green LED. Just a reboot loop of failed tries which eventually turns into a red LED after maybe 5 tries.

beta3 worked great to register device and do a simple LED blink test with WipperSnapper.

[brubell]

Did you flash CircuitPython on first, or just the TinyUSB bootloader?

Could you open up the Arduino serial monitor and paste the output here?

[ksprayberry]

I have the funhouse and had the same issue and had loaded circuitpython, I backed all the way up and used the esp webtool and erased my device and just started over. I reloaded the UF bootloader and then reloaded the wippersnapper beta and re-setup the secrets file and it seemed to fix the reboot loop. It still shows offline, but it fixed that loop.

[brubell]

I have the funhouse and had the same issue and had loaded circuitpython, I backed all the way up and used the esp webtool and erased my device and just started over. I reloaded the UF bootloader and then reloaded the wippersnapper beta and re-setup the secrets file and it seemed to fix the reboot loop. It still shows offline, but it fixed that loop.

Yeah, I spent a lot of time the past two days in the filesystem code. Beta.8 will (hopefully) solve a lot of the filesystem-related provisioning issues without needing to load CircuitPython.

[mikeysklar]

I have been flashing CircuitPython with the UF2 wippersnapper images provided. I'm just doing the double reset to bootloader and dropping the image on the drive. I tried a few more times with beta7, but no change in behavior (reboot loops). No info on the serial console for beta7 as the reboot happens quite quickly. beta3 does have valid serial console output, but after messing with it for a while yesterday it pretty much stops at Connecting to MQTT.....(with an endless period trail).

[brubell]

Could you please try beta.8? It's on the guide. We've done a lot of filesystem-related bugfixes in the latest version which may squash these issues.

[mikeysklar]

Dropped in beta8 wipper image, but got stuck in reboot forever loop every 20 seconds (cyan / blue LED only for connectivity. Same behavior as beta7 for me on the Metro M4 + Airlift Lite.

I dropped a CircuitPython 7.x image and wipped the filesystem:

Code: Select all

Adafruit CircuitPython 7.0.0-rc.1 on 2021-09-02; Adafruit Metro M4 Airlift Lite with samd51j19
>>> import storage
>>> storage.erase_filesystem()

Then reverted back to beta8 wipper and updated my secrets file. No luck. Still seeing reboot loop. I have not been able to grab any console output Arduino / screen. The reboot loop is too quick.

[brubell]

What operating system are you using?

[mikeysklar]

Mac OS (Mojave 10.14.6).

I can try with Pi OS.

[brubell]

Could you wiping the QSPI flash again and trying beta.10?

[mikeysklar]

You bet.

Installed CP7
Wiped filesystem with storage.erase_filesystem()
Installed wippersnapper.metro_m4_airliftlitebeta.10.uf2

1.0.0-beta.10
* Please edit the secrets.json file. Then, reset your board.
* ERROR: Default username found in secrets.json, please edit the secrets.json file and reset the board for the changes to take effect

updated secrets.json

stuck in reboot loop. No getting on-line or making contact with WipperSnapper.

I've not been able to pull anything off the console during reboot loops.

wipper_boot_out is limited to:

1.0.0-beta.10

[brubell]

Could you provide the output of the Arduino serial monitor?

[mikeysklar]

Got some data from the Arduino IDE console.

Code: Select all

14:39:32.106 -> Connecting to: io.adafruit.com
14:39:32.106 -> Connect result: 1
14:39:32.106 -> MQTT connect packet:
14:39:32.106 -> 	  [0x10], ~ [0x7E],   [0x00],   [0x04], M [0x4D], Q [0x51], T [0x54], T [0x54], 
14:39:32.106 -> 	  [0x04],   [0xC2],   [0x00],   [0x04],   [0x00], . [0x2E], i [0x69], o [0x6F], 
14:39:32.106 -> 	- [0x2D], w [0x77], i [0x69], p [0x70], p [0x70], e [0x65], r [0x72], - [0x2D], 
14:39:32.106 -> 	a [0x61], d [0x64], a [0x61], f [0x66], r [0x72], u [0x75], i [0x69], t [0x74], 
14:39:32.106 -> 	- [0x2D], m [0x6D], e [0x65], t [0x74], r [0x72], o [0x6F], - [0x2D], m [0x6D], 
14:39:32.106 -> 	4 [0x34], - [0x2D], a [0x61], i [0x69], r [0x72], l [0x6C], i [0x69], f [0x66], 
14:39:32.106 -> 	t [0x74], l [0x6C], i [0x69], t [0x74], e [0x65], 1 [0x31], 9 [0x39], 6 [0x36], 
14:39:32.106 -> 	7 [0x37], 9 [0x39], 5 [0x35], 1 [0x31],   [0x00],   [0x20], a [0x61], i [0x69], 
14:39:32.106 -> 	o [0x6F], _ [0x5F], e [0x65], v [0x76], I [0x49], I [0x49], 1 [0x31], 7 [0x37], 
14:39:32.106 -> 	q [0x71], c [0x63], 2 [0x32], G [0x47], G [0x47], 3 [0x33], N [0x4E], E [0x45], 
14:39:32.106 -> 	B [0x42], T [0x54], 0 [0x30], w [0x77], a [0x61], 8 [0x38], 6 [0x36], J [0x4A], 
14:39:32.106 -> 	X [0x58], 4 [0x34], f [0x66], e [0x65], A [0x41], H [0x48],   [0x00],   [0x20], 
14:39:32.106 -> 	a [0x61], i [0x69], o [0x6F], _ [0x5F], e [0x65], v [0x76], I [0x49], I [0x49], 
14:39:32.106 -> 	1 [0x31], 7 [0x37], q [0x71], c [0x63], 2 [0x32], G [0x47], G [0x47], 3 [0x33], 
14:39:32.106 -> 	N [0x4E], E [0x45], B [0x42], T [0x54], 0 [0x30], w [0x77], a [0x61], 8 [0x38], 
14:39:32.106 -> 	6 [0x36], J [0x4A], X [0x58], 4 [0x34], f [0x66], e [0x65], A [0x41], H [0x48], 
14:39:32.106 -> 	
14:39:32.106 -> Client sendPacket returned: 128
14:39:32.389 -> Read data:		  [0x20], 
14:39:32.389 -> Packet Type:		  [0x20], 

[brubell]

This output seems truncated.. does it reboot after that?

[mikeysklar]

Yes, it resets and presents the same MQTT packet data. I can provide a longer (repeated dump) for you to verify if you wish.