QTPY S3 will not load the WIPPER drive

[Timeline8]

Last night, following guide on https://io.adafruit.com/Timeline/device ... uf2/step-2 And also referencing https://learn.adafruit.com/adafruit-qt- ... pper-setup Booted Qt Py S3 into bootloader mode with double press of the reset button. File INFO_UF2.TXT reports the following:

TinyUF2 Bootloader 0.18.2 - tinyusb (0.15.0-566-gf1e006d09) Model: Adafruit QT Py ESP32-S3 (4M Flash, 2M PSRAM) Board-ID: ESP32S3-QTPy-N4R2-A Date: Mar 22 2024 Flash Size: 0x00160000 bytes

Downloaded latest version of Whippersnapper for my board named wippersnapper.qtpy_esp32s3_n4r2.1.0.0-beta.83.uf2

Drag and dropped file onto QTPYS3BOOT

Board restarted but I was not offered a WIPPER drive nor any drive at all. Tried hitting reset and also hard power cycling the board by pulling the USB. No drive appearing and NeoPixel is showing a steady green-yellow color. Board was previously running CircuitPython however I am not presented with a CIRCUITPY drive either. Confirmed chip silkscreen on the board is “FHR2...” so 4MB Flash/2MB PSRAM.

Following instructions on https://learn.adafruit.com/adafruit-qt- ... tory-reset, downloaded Factory Reset Firmware UF2 and after soft reset confirmed visually by the LED "NeoPixel rainbow swirl example” was running.

Double tapped reset button to re-enter boot loader. Drive QTPYS3BOOT connected. Dragged and dropped same wippersnapper.qtpy_esp32s3_n4r2.1.0.0-beta.83.uf2 onto it. After it loaded and drive ejected, back to green-yellow steady Neopixel and no drives showing. Unplugged USB and plugged back in. Same result. Steady green-yellow neopixel and no drive loaded at all let along the WIPPER drive expected. So impossible to progress past https://io.adafruit.com/Timeline/device ... uf2/step-6

Running an intel 2019 iMac on Sonoma 14.5 (23F79)

Additional background info: Ordered board from Digikey and it was back ordered. Once Digikey got new stock I got my board last week, so I assume a newer build (W22553A). When received it had an older bootloader (I think it was v0.15.x) so I booted into the ROM bootloader, used the ESP Web Flasher (on Chrome) to erase the board then load the v0.18.2 combined.bin file. Then loaded the latest beta version of CircuitPython and ran a few things. Then I wanted to try it on IO and went through the process outlined above. Nothing has been added (no header pins), removed, or changed from the QTPY. It is as it came out of the pink bag.

And just for yucks, just now downloaded a fresh copy of the WipperSnapper u2f (has the same name), entered bootloader, and drag/dropped it in again. No change to behavior and no drive appearing.

[brentru]

@tyeth Do you have a Adafruit QT Py ESP32-S3 (4M Flash, 2M PSRAM) you can try this with?

[tyeth]

I'm afraid not with me this week, but will schedule for next week when I'm back at base.

[Timeline8]

New information. Short version is it would seem there is something wrong with the beta.83 (latest as of this writing) version of WipperSnapper.

Today I received my backordered S3 REV TFT Feather that I ordered at the same time as the QTPY S3 from Digikey. I tried to load WipperSnapper on it and had the exact same experience as the QTPY S3... no WIPPER drive.

When I first got my S2 version some months again I had connected that one (and since removed it from the IO service) so I know that one worked. Downloaded the latest beta.83 for that S2 board and the exact same behavior. No Wipper drive and the NeoPixel stays a sort of greenish-yellow color.

Found the online archive of older versions and went back to https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/releases/tag/1.0.0-alpha.80 as that was released about the same time as I got my S2.

Downloaded the S2 REV TFT version and loaded it. Success! Was running CircuitPython previously so it did show up as CIRUITPY drive, but verfied it had the wipper_boot_out.txt file showing.

I then repeated the same version for the S3 REV TFT (which never had CircuitPython loaded) and again successful and I get the WIPPER drive.

I then repeated this for the QTPYS3, SUCCESS!

By the way, on all of these "alpha.80" versions the wipper_boot_out files says "Firmware Version: 1.0.0-alpha.79".

And finally on the QTPY S3 I tried the latest beta.83 again to see if maybe loading the older version helped. Nope. Now boots up showing no drive at all.

I didn't bother to check the three versions (alpha.81, alpha.82, & beta.82) between the alpha I tried and the latest beta.83 so I have no idea which version broke it. I would recommend that someone reading this try any IO compatible board loading beta.83 and seeing if you can get it to work. You apparently don't need only the QTPY S3.

[tyeth]

Brilliant, thanks for that useful extra information @Timeline8

Can you try another go with v83, but when the drive fails to show up then manually reboot the device (using the reset button) and see if the drive shows up afterwards. Secondly can you try viewing the data sent over the serial port, as the device boots, it should be informing us of the problem. You can use a chrome based browser to do this at https://webserial.io/ or with some software on your mac like Thonny/Mu/Tio/ArduinoIDE.

In addition to that testing, can you try this collection of build assets instead of v83. It has a little more error logging and recovery than v83, so more should be displayed in the serial monitor: https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/actions/runs/9481598472/artifacts/1593474436 [You will need to be logged in to download the zip]

[Timeline8]

I should have mentioned in my original posts that in every case I both pushed the reset and disconnected/reconnected the USB in attempts to get the WIPPER drive to show up. With "83" none of the three boards came up with a drive.

I brought the S3 REV TFT to work with me this morning and had a slightly different experience on my Win 10 machine but still ultimately failed. Basically, plugged in the board, verified I still had Alpha.80 loaded, double RST into the Adafruit Bootloader which by the way, I should mention this time on this board I decided not to upload the bootloader and left it as received which is...

TinyUF2 Bootloader 0.12.3 - tinyusb (0.12.0-203-ga4cfd1c69) Model: Adafruit Feather ESP32-S3 Reverse TFT Board-ID: ESP32S3-FeatherRevTFT-revC Date: Feb 2 2023

I can update that to 0.18.2 if you like.

Anyway, downloaded the standard beta.83 automatically offered via the "Add new device" screens at the IO adafruit page, dragged and dropped it onto the FTHRS3BOOT drive and I this time I got the WIPPER drive. Checked the wipper_boot_out to verify it was beta.83 (it was). Weird thing is the TFT was still showing the Adafruit multicolor bootloader screen which I don't think is normal. So I pressed the RST button. No more WIPPER drive after restart and TFT is blank. Pulled the USB, reconnected, still no WIPPER drive. So my one opportunity to see it was right after the programming when it auto restarted and loaded WIPPER. All subsequent attempts via RST button or power cycling to get it back have failed.

I did go to the webserial IO page on Chrome browser and I can see that it is "CONNECTED - Unknown Device (303a:1001)" and changes to "unplugged" when I remove the board or RST into the bootloader and then reconnects automatically when I restart the board. But I am not seeing anything else on the screen. So either no data is coming through or I need to open something first maybe? I didn't mess with the defaults which are 115200, buffer=255, 8, none, none, 1.

When I get some free time today while at work I will try the collection of build assets (already downloaded), but if I don't get back to it today then I will try it tonight at home on the iMac.

[brentru]

Running an intel 2019 iMac on Sonoma 14.5 (23F79)

Just because I haven't seen this before and that Sonoma is an older OS, do you have another computer to try this on?

[Timeline8]

Ummm, Sonoma is 14. OS 15 (Sequoia) was just announced literally 4 days ago. Perhaps you were thinking of a different earlier OS?

And as I stated in my previous post

I brought the S3 REV TFT to work with me this morning and had a slightly different experience on my Win 10 machine but still ultimately failed.

and described the same issues trying load Wippersnapper on a Windows 10 computer. I will allow you to call that one older though. ;)

[brentru]

I was able to load the latest version of WipperSnapper onto my QT PY ESP32-S3 this morning. I'm running macOS Ventura.

TinyUF2 Bootloader 0.13.0 - tinyusb (0.14.0-364-gc0d79457f)
Model: Adafruit QT Py ESP32-S3
Board-ID: ESP32S3-QTPy-A
Date: Mar 14 2023

Adafruit.io WipperSnapper
Firmware Version: 1.0.0-beta.83
Board ID: qtpy-esp32s3
MAC Address: F4:12:FA:44:07:EC

However, the exact hardware I tested on is different from what you tested on. I'm going to order the ESP32-S3 Feather Reverse TFT and the Adafruit QT Py S3 with 2MB PSRAM WiFi Dev Board with STEMMA QT from the shop so I have stock, and can test these for you as soon as I get them this week.

Becuase you are running Sonoma, and we've seen similar issues with CircuitPython (which uses the same USB fs method for loading firmware), could you try the steps outlined on this page: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#macos-sonoma-14-dot-x-disk-errors-writing-to-circuitpy-3160304

[brentru]

Also, could you please provide a link to the DigiKey page where you bought your board?

[Timeline8]

Yes, I was aware of the Sonoma issue but thought that was (sort of) fixed on the latest Sonoma update. Maybe I misunderstood that. But the weird thing is when I loaded the older version of WipperSnapper is worked fine which I would think what version of WS loaded shouldn't matter to a Sonoma write operation issue. And I had the same issue trying to load the latest WS with my Windows 10 machine.

However tonight I will give the remounter script with terminal a try. But it should be noted that I have never had any issues with mounting or writing to my boards when running CircuitPython. Only the specific attempt at installing WipperSnapper has issues.

The QT PY S3 purchased was Digikey part number 1528-5700-ND https://www.digikey.com/en/products/detail/adafruit-industries-llc/5700/21283799?s=N4IgTCBcDaIIwFYwA4C0CDsAGLqByAIiALoC%2BQA

And the Reverse TFT S3 Feather was Digikey part number 1528-5691-ND https://www.digikey.com/en/products/detail/adafruit-industries-llc/5691/18627502?s=N4IgTCBcDaIIwFYwA4C0CBsBOOqByAIiALoC%2BQA

Both were ordered on May 21, 2024 and both were out of stock. Once they got stock, Digikey shipped the QT PY on June 3 and the Feather shipped June 7.

[brentru]

Okay, I have ordered both of these Prods. and should have them by Weds. at the latest to test with your exact hardware.

[Timeline8]

Note that the NeoPixel shows the “wippersnapper lime” color when it should be showing the WIPPER drive, so assume below anywhere I say WIPPER drive the NeoPixel is indicating the proper lime color. Testing using the S3 Reverse TFT that has never had anything but wippersnapper attempted and bootloader v0.12.3 as received from DigiKey (my QtPy I did upload the bootloader to 0.18.2 and had same outcome)

Booted up REV TFT S3. Verified no WIPPER drive from last time I tried setting up.

Double RST into bootloader. Then drag and dropped (freshly downloaded) wippersnapper.feather_esp32s3_reverse_tft.1.0.0-beta.83.uf2 onto drive. Installed and reset with WIPPER drive showing.

Ejected drive and disconnected board from USB. Plugged back in. WIPPER drive did not reload.

Double RST into bootloader. Then drag and dropped wippersnapper.feather_esp32s3_reverse_tft.1.0.0-beta.83.uf2 onto drive. Installed and reset with WIPPER drive showing.

Ran in the terminal (replacing all instances of CIRCUITPY with WIPPER from the learning guide)

disky=`df | grep WIPPER | cut -d" " -f1`
sudo umount /Volumes/WIPPER
sudo mkdir /Volumes/WIPPER
sleep 2
sudo mount -v -o noasync -t msdos $disky /Volumes/WIPPER

Board remounted as WIPPER drive. Ejected WIPPER and power cycled board. WIPPER drive never to be seen again.

Mac then reported “Whippersnapper hates you!”. (OK that last past I just made up. ;) )

[Timeline8]

One more test...

Downloaded previous version wippersnapper.feather_esp32s3_reverse_tft.1.0.0-beta.82.uf2 Installed on same board (S3 Rev TFT). WIPPER appeared. Did not run the shell script this time. Rebooted the board three times by completely removing power. WIPPER appeared reliably all three times.

Reinstalled wippersnapper.feather_esp32s3_reverse_tft.1.0.0-beta.83.uf2. WIPPER appeared. Did not run the shell script. Rebooted the board three times by completely removing power. WIPPER never appear again.

[brentru]

@Timeline8 Before the end of the workday today, I was able to replicate the issue you are experiencing. It seems that the problem with the drive not appearing is intermittent for me, and I haven't been able to consistently trigger it using any methods. When the drive is not mounted, I do not see any output on the serial.

I plan to compile a development build of beta 83 for the esp32s3 reverse TFT when I return on Monday. This build will include some options for me to view the ESP-IDF debug output from the serial, the absolute latest board support package, and the latest libraries. I can keep troubleshooting this issue from there.

Thank you for your continued debugging and patience while I figure out exactly what's happening.

[Timeline8]

You are welcome for whatever bit of help I was able to provide. I went to load wippesnapper because a question on the Adafruit IO forum prompted me to see something for myself, but I never got to that point as I had this issue and went down the rabbit hole (I don't even remember what it was I wanted to see). However I am quite pleased if I was able to contribute in some small way to improving the product as I think the entire IO concept is fantastic even if the wippersnapper method is not yet where I would like it to be. I am using the IO service via CircuitPython with the Adafruit_IO library, which works very nicely. I don't have the skills to contribute back to the community with coding but if I can uncover bugs, even if accidentally, and help with the initial testing, I'll take it.

[brentru]

@Timeline8 We found an issue with this specific board and the latest board support package version. I'm going to work with Espressif to debug and patch it.

https://github.com/espressif/arduino-esp32/issues/9936

[Timeline8]

Thank you.

But to note again, I found this problem on the 3 different model boards I tried. The S3 Rev TFT feather was simply the last one I tried again where I verified the latest version of WipperSnapper fails to show the WIPPER drive and going back just one version of the WipperSnapper firmware (on my previous tests I want back a few versions) works and then going back to the latest breaks it again. I didn't repeat this test for the QT PY S3 (with PSRAM) not the S2 Rev TFT Feather, both of which failed to show me the WIPPER drive running the latest WipperSnapper. So not only different boards but also different -S2 & -S3 Espressif modules.

Hopefully our friends at Espressif will come up with a root cause that will explain all the boards acting this way. Thanks again for pursuing this.

[brentru]

Hey @Timeline8 - I just released a new version of WipperSnapper, beta 85. It's built from the latest arduino libraries and board support package 3.0.0. When tested with my S3 Rev TFT, I didn't experience the issue where it fails to show the Wipper drive.

Could you give it a shot and let me know if this works (or works better)?

[Timeline8]

Of the three boards I had this issue, the S2 REV TFT is currently deployed on something else I don't want to take down. And I think I took my S3 Rev TFT into work and left it there so that will have to wait until tomorrow.

However my QtPy S3, which actually was the first one that spawned this report properly shows the CIRCUITPY drive with beta 95 (this board previously has CircuitPython loaded). I still had the previous version of WipperSnapper on it and when I plugged it in it was doing the steady "lime" NeoPixel and no drive showing. Loaded the beta 85 and when it was done, while it didn't initially show a drive, it did after a soft reset via the RST button (tried it twice) and once again after power cycling. So looks good so far.

If I don't forget to grab my S3 REV TFT tomorrow and throw it into my bag when I come home, I will test it tomorrow night. That one has never had anything on it other than WipperSnapper attempts so I would like to verify I get the WIPPER drive on that one and will report back.

I did follow through with the QyPy S3 and the IO service autodetected it. I added the SHT41 Temp and Humidity sensor via Stemma and IO is properly showing my window air conditioner setting shown on its display is a big fat lie! ;) Ha! (I have it set for "73" while the SHT41 says it is 78 at my desk).

[Timeline8]

OK, well, not great news but I do have some new information.

Brought home the ESP32-S3 Reverse TFT Feather from work. Loaded WipperSnapper beta 85 on it. After self restart I see the Wipper drive, however on subsequent reboots including power cycling, I never see the WIPPER drive again, so that is the same behavior as before. Tried reloading the WipperSnapper .yf2 file a second time, same result, WIPPER appears after the board self restarts (and by the way the bootloader screen remain on the screen on first the self reboot, but subsequent reboots no WIPPER drive.

I did go one step further than before that may be helpful. I reloaded the WS .uf2 file again in order to get the initial WIPPER drive to show. This time I updated the secrets file with my credentials and I had the IO page open in Chrome. When I rebooted the board, while I didn't see the WIPPER drive as expected, IO auto detected the ESP32-S3 Reverse TFT Feather and added it to my IO page. I then plugged in my SHT41 temp/Humidity sensor and was able to create the three default feeds. It is now logging that data.

So in summary, the Beta 85 appeared to fix the issue with my QtPy S3 and I get the MCU drive showing every time (in that case the CIRUITPY drive). The ESP32-S3 Reverse TFT Feather is not acting any differently on 85 than it did on 84, however this time I went further than I had previously and while I am not presented in Mac OS with any sort of MCU drive other than the initial reset after install, WipperSnapper does appear to be running and with proper credentials in the secrets file can be added to IO and feeds added & updated from it.

And to show I loaded the correct file, before I added the credentials to the secrets file and while I was still able to see the WIPPER drive, the wipper_boot_out.txt file showed: Adafruit.io WipperSnapper Firmware Version: 1.0.0-beta.85 Board ID: feather-esp32s3-reverse-tft MAC Address: 34:B7:DA:58:87:CC ERROR: Invalid IO credentials in secrets.json! TO FIX: Please change io_username and io_key to match your Adafruit IO credentials!

[brentru]

@Timeline8 Thanks for the additional info, I was able to reproduce this within TinyUSB and have filed an issue: https://github.com/adafruit/Adafruit_TinyUSB_Arduino/issues/436. When @hathach is available, we'll work together on resolving it.

Again, thank you for your patience as we work through this bug.

[Timeline8]

Always good to hear that what I think I observed is verifiable by someone else. Thanks for continuing to look into this. Hope you get it sorted out.

[brentru]

@Timeline8 Apologies that this took so long to get sorted, it was waiting on a fix within TinyUSB which landed earlier this morning.

Today, I integrated the updated version of TinyUSB into the ESP32-S3 builds and tested it on an Adafruit Feather ESP32-S3 with my Mac.

I'm currently working on releasing beta 89, which should be available within the next few hours. Once released, please try it and let me know how it works for you.

Thanks!

[Timeline8]

Hi Brent,

I just tried beta 89 on a Qt Py S3 and a ESP32-S3 Reverse TFT Feather. Success in that both show the drive on my Mac even after power cycling both boards. So that seems to be solved.

However, I did notice one strange behavior that differs from my CircuitPython loaded boards and I can not recall what it did on previous Wippersnapper deployments, but I suspect it they acted the same I would have noticed. When I eject the board (does it the same on both boards), after a heartbeat automatically remounts with no time to unplug the board while unmounted unless you are anticipating it. So you get the Mac "Disk Not Ejected Properly" message. It is probably not an issue if you ejected it first so that all files were properly written and closed, but this might put off some people who otherwise are always careful to eject volumes before unplugging and still getting this pop up.

Edit: well hours later I may have spoken too soon. The above I only checked that the drives showed up properly and didn't go any further. But since I had both board setup I wanted to try something with Wippersnapper. Short version is I updated the secrets file on both boards and neither will connect with IO and they both keep disconnecting and reconnecting roughly every minute. On the Reverse S3 I regenerated the secrets file just in case but no change in behavior.

[Timeline8]

Just put my Qt Py S3 back on. Loaded beta-85 back onto it and with secrets.json file already on the drive the board connected with IO service immediately. Oddly now that board shows the drive when I unplugged it and plugged it back in. However it keeps disconnecting and reconnecting over and over. Although stopped after I started to play with the neopixel through IO.

I then reloaded beta-89 and it doesn't reconnect.

Off to bed, it's late!

[brentru]

Success in that both show the drive on my Mac even after power cycling both boards. So that seems to be solved.

Glad the primary issue is solved

hort version is I updated the secrets file on both boards and neither will connect with IO and they both keep disconnecting and reconnecting roughly every minute. On the Reverse S3 I regenerated the secrets file just in case but no change in behavior.

Could you file a separate issue for this behavior? Thanks!

[Timeline8]

I have opened issue #628 to address this.