Many CLUE boards unstable on Mac

For CircuitPython issues, ask in the Adafruit CircuitPython forum.

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
Robert_McLeod
 
Posts: 5
Joined: Mon Aug 31, 2020 8:38 pm

Many CLUE boards unstable on Mac

Post by Robert_McLeod »

I am teaching a remote class to 100 freshman students, many of whom run new Macs. They and I are able to install the Arduino IDE on MacOS and run the Blinky example program. Then within a few minutes, MacOS displays a message about an improper ejection of the CLUE, even though it is still plugged in. If the board is (then) manually disconnected and reconnected, it does not appear in the Finder and cannot be used. We also see the board disappearing from the serial port list while still showing up in Finder. All of this is happening within about 10 minutes of finishing the install and beginning to program.

Using the reset button on the back generates another "improper ejection" notice from MacOS, even though the CLUE is no longer visible in the finder, then the CLUE reappears in the finder. Dragging the "adafruint.....uf2" file to the CLUE causes a reboot into CIRCUITPY as expected, but now the power LED flashes green, red and blue(5x). I can now upload a program via the Arduino IDE but the power light turns completely off. After ~10 minutes of use, the entire process repeats, starting with an unexpected ejection complaints from MacOS.

I'm really desperate because this is impacting a large fraction of my class and also my own board, so they can't learn and I can't teach. We tested a CLUE extensively this summer with PC and MAC before placing the large order and never saw this issue, but that particular Mac was 7 years old, so we're wondering if there's a new driver or OS issue.

Thank you!

User avatar
westfw
 
Posts: 2008
Joined: Fri Apr 27, 2007 1:01 pm

Re: Many CLUE boards unstable on Mac

Post by westfw »

MacOS displays a message about an improper ejection of the CLUE, even though it is still plugged in.
This part at least is normal. The "fake disk" that the bootloader implements disappears when the board is reset (which happens when you upload a new Arduino sketch. I'm not sure about circuitPython.) It SHOULD reappear as a new disk, at least if the sketch includes USB support (Blink might not. No USB code running means no response to USB?)

All of the "native USB" boards have similar problems. Most desktops just aren't set up to have a USB disappear when the sketch reboots, re-appear a moment later when the bootloader runs, disappear again when the bootloader is done, and re-appear when the sketch starts :-( I usually just use a "double tap" reset - pushing the reset button twice "quickly" should force the board into the bootloader, ready to accept a new upload.

User avatar
Robert_McLeod
 
Posts: 5
Joined: Mon Aug 31, 2020 8:38 pm

Re: Many CLUE boards unstable on Mac

Post by Robert_McLeod »

I really appreciate the quick response, but I must not have communicated clearly. The CLUE, long after reset and often while running a program, simply is ejected, generating an improper eject message. This apparently damages the image on the CLUE so that it can't be used again without a hard reset. No boot loaders are involved. The CLUE is unusable because it requires a hard reset and reinstall every few minutes after this unwanted ejection occurs. I have use Arduino's for years in this class and never experienced anything like this.

User avatar
Robert_McLeod
 
Posts: 5
Joined: Mon Aug 31, 2020 8:38 pm

Re: Many CLUE boards unstable on Mac

Post by Robert_McLeod »

Update. This behavior is the same on either MacOS 10.15.4 or Windows 10.

1) Double click reset button and CLUE shows up in file system as FTH840BOOT
2) Copy adafruit-circuitpython-clue_nrf52840_express-en_US-5.3.1.uf2 into the drive. Dismout and remount as CIRCUITPY
3) The multicolor LED immediately flashes an error code green(1), yellow(1), blue(5) which seems to indicate a line of code.
4) Upload the Blinky example. The multicolor LED turns off, the onboard red LED blinks and the drive vanishes from the file system.
This is displayed in the message area: Upgrading target on /dev/cu.usbmodem14401 with DFU package /private/var/folders/wd/mjk335qn6lbg4_xppdcx4dxnjpk68c/T/arduino_build_706493/Blink.ino.zip. Flow control is disabled, Single bank, Touch disabled
5) Unplug USB and plug back in: no eject warning on unplug, no drive appears on plug in, but uploads of Blinky still work.

This is in addition to the spontaneous dismounts and the device not appearing on the serial port list. Since it is simple, reproducible and produces an error code, I thought it might be helpful.

User avatar
danhalbert
 
Posts: 4654
Joined: Tue Aug 08, 2017 12:37 pm

Re: Many CLUE boards unstable on Mac

Post by danhalbert »

I had a discussion with Arielle Blum in discord about this.

In step 3 above, the error code is probably indicating a bug in the code.py program. If you can get CIRCUITPY back, then rename code.py to be something else, like codex.py, so that it doesn't run on startup.

Arielle mentioned the DriveDx disk utility program. Do you have this program installed, or some other disk utility program? Do the students all have this installed uniformly?

Just to be clear about the various pieces of software:

1. The bootloader is what presents the CLUEBOOT drive. That software is in flash permanently. The CLUEBOOT drive is a "fake" drive: it does not represent a true USB drive. When you copy a .uf2 file onto CLUEBOOT, the fake drive takes that file and writes it into flash. Then the board restarts. The bootloader runs the loaded program immediately. The bootloader is not CircuitPython, and it does not present CIRCUITPY.

2. CircuitPython is "just another program", that can be loaded via a .uf2 file via the bootloader. It is not the bootloader.

3. The Arduino blink program overwrites CircuitPython when loaded, so CIRCUITPY will not appear.

User avatar
danhalbert
 
Posts: 4654
Joined: Tue Aug 08, 2017 12:37 pm

Re: Many CLUE boards unstable on Mac

Post by danhalbert »

Also, just to let you know, a number of us are using the latest MacOS, and don't see this problem, so it may be something with the setup of their Macs, though I would be surprised that all the students have the same issue, unless they have all installed some third-party utility on your recommendation or requirement.

User avatar
Arielle
 
Posts: 2
Joined: Fri Mar 13, 2015 5:35 pm

Re: Many CLUE boards unstable on Mac

Post by Arielle »

I am co-teaching the course with Robert_McLeod and was on the Discord server talking to some wonderful folks about this issue. They suggested that I summarize our Discord discussion and post here:

The issue(s) that my colleague, Robert McLeod are occurring on ~50+ of our student's Macs, the PC students had some issues, but we have resolved them.

All of the Macs are newer Macs, purchased in the last 1-2years. Running OS at or newer than macOS 10.14.4
These Macs have the antivirus uninstalled, these Macs are personal use computers, not controlled by the school and therefore lack some of the associated bloatware.
These Macs do not have the DriveDx installed.
All the students are using USB cables that were provided in their kit, this cable is NOT a charging cable, it is a cable capable of data-sync
For many of the students, if the CLUEBOOT shows up on their Mac as mounted, and then they go through the steps for getting to CIRCUITPY, as outlined here: https://learn.adafruit.com/adafruit-clue/circuitpython
then we end up with a warning message and then unplug, plug back in, and the Mac will never again recognize the CLUE, no drive will ever be shown again on the Mac.

Robert_McLeod was able to reproduce this situation on his own newer Mac, I was not, I am running both a PC and a Mac with macOS 10.14.2 so I am unable to reproduce the issue that the students have, but Robert_McLeod was able to reproduce it! Exciting!

Since Robert_McLeod was able to reproduce the issue, the CLUE no longer mounts on his PC, nor on his Mac. Previously, Bob had an issue where he was unable to have the CLUE mount on the Mac but was able to resuscitate it using the PC.

I am hoping to get Bob's CLUE later today and try to interact with it on either/both my older Mac and PC. If I am able to resuscitate the CLUE, then I am going to give it back to Bob and then see if his newer Mac can recognize it. If it does, then we may have a solution.

On the Discord, it was pointed out, that this whole issue may be due to the particular dongle that the Mac users are using since the newer Macs only come with USB-C connections. If we replace the cable + dongle with a USB-C to micro capable of data-sync, then the student's and Bob's Macs might be able to recognize the CLUE.

Looking for any assistance on this matter. Thank you so much in advance!

User avatar
danhalbert
 
Posts: 4654
Joined: Tue Aug 08, 2017 12:37 pm

Re: Many CLUE boards unstable on Mac

Post by danhalbert »

@Robert_McLeod If you double-click the reset button on the CLUE, do you no longer see CLUEBOOT on both the Mac and the PC?
When you double-click, what's the status of the red LED on the back? Is it pulsing slowly (about once per second), or is it flashing quickly, or is it doing nothing?

Do any of the CLUEs show FTHR840BOOT instead of CLUEBOOT?

What is the contents of the INFO_UF2.TXT file on CLUEBOOT, assuming you can see it?

User avatar
Robert_McLeod
 
Posts: 5
Joined: Mon Aug 31, 2020 8:38 pm

Re: Many CLUE boards unstable on Mac

Post by Robert_McLeod »

@danhalbert. Thanks for the rapid attention to this. If I double-click the reset, yes, FTHR840BOOT mounts. This happens even when the CIRCUITPY drive has dismounted itself and does not mount even if unplugged and reattached. The neoPixel is green and the red LED is not lit. The FTHR840BOOT drive contains a file INFO_UF2.TXT with these contents:

UF2 Bootloader 0.2.9 lib/nrfx (v1.1.0-1-g096e770) lib/tinyusb (legacy-755-g55874813) s140 6.1.1
Model: Adafruit Feather nRF52840 Express
Board-ID: NRF52-Bluefruit-v0
Bootloader: s140 6.1.1
Date: Feb 22 2019

This situation lasts for about 4 minutes before the FTHR840BOOT disappears from the Finder (actually, Finder crashes) with a message "Disk not ejected properly". When Finder is restarted, there is no CLUE. NOW the red light is flashing at 1/2 Hz and the neoPixel is off.

User avatar
danhalbert
 
Posts: 4654
Joined: Tue Aug 08, 2017 12:37 pm

Re: Many CLUE boards unstable on Mac

Post by danhalbert »

Robert_McLeod wrote:This situation lasts for about 4 minutes before the FTHR840BOOT disappears from the Finder (actually, Finder crashes) with a message "Disk not ejected properly". When Finder is restarted, there is no CLUE. NOW the red light is flashing at 1/2 Hz and the neoPixel is off.
The 4 minute timeout is actually expected. This bootloader does not stay in bootloader mode after several minutes (unlike CPX, which will stay in bootloader mode forever). I would expect the "not ejected properly" message. It -should- be harmless; it's like pulling a USB drive out unexpectedly.

The Finder actually crashing is new bad behavior. I will try to reproduce this. But if double-click restores FTHR840BOOT, then no problem. We have seen cases where the Mac needs to be rebooted to get the USB port to work with the board again.

But do you see this disconnect behavior when CIRCUITPY is running and you're running a CircuitPython program?

User avatar
Robert_McLeod
 
Posts: 5
Joined: Mon Aug 31, 2020 8:38 pm

Re: Many CLUE boards unstable on Mac

Post by Robert_McLeod »

I find this really confusing - the CLUE can only be used for 4 minutes at a time before it automatically dismounts? That will make using it for teaching or projects practically impossible.

CIRCUITPY
1) Double click reset. FTHR840BOOT mounts. Drag in adafruit....uf2, Two improper dismount messages occur and CIRCUITPY remounts. neoPixel flashes green, yellow,blue (5x). No red LED
2) Drag "code.py" for the Blinky example to CIRCUITPI. neoPixel solid green and red LED flashing consistent with python code. Unlike when using the Arduino IDE, the CLUE drive does not immediately dismount when new code is uploaded.
3) 20 minutes of operation and the CLUE is still running Blinky and mounted as CIRCUITPY.
4) Close mu editor to free up serial port. Upload Blinky from Arduino IDE. CIRCUITPY immediately ejects improperly and Finder crashes. neoPixel turns off. Red LED indicates new uploaded Blinky program is now running.

User avatar
danhalbert
 
Posts: 4654
Joined: Tue Aug 08, 2017 12:37 pm

Re: Many CLUE boards unstable on Mac

Post by danhalbert »

Robert_McLeod wrote:I find this really confusing - the CLUE can only be used for 4 minutes at a time before it automatically dismounts? That will make using it for teaching or projects practically impossible.
It's only when it's in bootloader mode (BOOT drive showing), when it's waiting to load a new program, that only lasts for a few minutes. That timeout could be removed; I'm not sure for the original motivation for that timeout. Normally, one would just double-click again to get back to bootloader mode. In CIRCUITPY, it should stay mounted forever.

(Qeury about timeout here: https://github.com/adafruit/Adafruit_nR ... issues/164)

The MacOS crash is bad, and we should figure that out. But it's may be a good reason for removing that timeout.
4) Close mu editor to free up serial port. Upload Blinky from Arduino IDE. CIRCUITPY immediately ejects improperly and Finder crashes. neoPixel turns off. Red LED indicates new uploaded Blinky program is now running.
The "ejects improperly" is also expected. Unfortunately, there's no way for a USB drive to signal the host computer that it wants to eject.

Locked
Please be positive and constructive with your questions and comments.

Return to “CLUE Board”