STM32F405 doesn't mount as CIRCUITPY on macOS with 5.0.0-beta.2

[anecdata]

Using macOS Catalina (10.15.2), can't get the STM32F405 to mount as CIRCUITPY under 5.0.0-beta.2. Using 5.0.0-beta.1, it mounts fine.

A one-liner code.py with just a single print statement seems to run to completion (pulsing green NeoPixel), but no sign of the CIRCUITPY device using system_profiler SPUSBDataType, or as a USB Volume. In bootloader mode, it shows up fine (via system_profiler SPUSBDataType or dfu-util). Tried re-downloading beta.2, reloading into device, power-cycling, etc.

Switching back and forth between beta.1 and beta.2, the behavior looks consistent: with beta.1 it always mounts, with beta.2 it never mounts.

[jerryneedell]

I have reproduced this on a Linux system -- no CIRCUITPY or /dev/ttyACM0 device
The issue actually began before the 5.0beta-2 tag -- the first build I have that fails to mount is:
adafruit-circuitpython-feather_stm32f405_express-en_US-20191218-25df6e6.bin

Interestingly -- there is no information in dmesg when I plug in or reset the board. The board does not appear to be communicating with the Linux box at all..
The status neopixel is "breathing" green -- looks like a normal startup but no /dev/ttyACM0

For comparison
CP 5.0Beta.1 and adafruit-circuitpython-feather_stm32f405_express-en_US-20191212-6c3d555.bin
load and boot OK - CIRCUITPY and /dev/ttyACM0 are available.

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.

Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 5.0.0-beta.1-50-g6c3d555b8 on 2019-12-12; Feather STM32F405 Express with STM32F405RG
>>> 

dmesg output is normal with these builds

[Sat Dec 21 05:18:55 2019] usb 3-2.2.2: USB disconnect, device number 86
[Sat Dec 21 05:18:58 2019] usb 3-2.2.2: new full-speed USB device number 87 using xhci_hcd
[Sat Dec 21 05:18:58 2019] usb 3-2.2.2: New USB device found, idVendor=239a, idProduct=805a
[Sat Dec 21 05:18:58 2019] usb 3-2.2.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[Sat Dec 21 05:18:58 2019] usb 3-2.2.2: Product: Feather STM32F405 Express
[Sat Dec 21 05:18:58 2019] usb 3-2.2.2: Manufacturer: Adafruit Industries LLC
[Sat Dec 21 05:18:58 2019] usb 3-2.2.2: SerialNumber: C30062001105D45305733302
[Sat Dec 21 05:18:58 2019] cdc_acm 3-2.2.2:1.0: ttyACM0: USB ACM device
[Sat Dec 21 05:18:58 2019] usb-storage 3-2.2.2:1.2: USB Mass Storage device detected
[Sat Dec 21 05:18:58 2019] scsi host7: usb-storage 3-2.2.2:1.2
[Sat Dec 21 05:18:59 2019] scsi host7: scsi scan: INQUIRY result too short (5), using 36
[Sat Dec 21 05:18:59 2019] scsi 7:0:0:0: Direct-Access     Adafruit Feather STM32F40 1.0  PQ: 0 ANSI: 2
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: Attached scsi generic sg2 type 0
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: [sdc] 4089 512-byte logical blocks: (2.09 MB/2.00 MiB)
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: [sdc] Write Protect is off
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: [sdc] Mode Sense: 03 00 00 00
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: [sdc] No Caching mode page found
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[Sat Dec 21 05:18:59 2019]  sdc: sdc1
[Sat Dec 21 05:18:59 2019] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[Sat Dec 21 05:19:00 2019] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

[jerryneedell]

It appears that PR #2395 introduced this issue
adafruit-circuitpython-feather_stm32f405_express-en_US-20191218-25df6e6.bin
does not mount -- no information via dmesg

adafruit-circuitpython-feather_stm32f405_express-en_US-20191218-f2b1aee.bin
does mount normally

It is not clear why this PR would cause this since it was related to nrf boards....but it did incorporate changes to tinyusb

[dhalbert]

Tagging @hathach here: could you take a look? There were many TinyUSB changes in #2395 as well as the nrfx update.

[phrogger]

I have reproduced this on a Windows 10 System -- no CIRCUITPY

[hathach]

This will be fixed by #2379 (just merged now) , latest tinyusb now leaves the VBUS sense configuration up to application to decide e.g STM32f405 requires to set hw vbus sense, while stm32f411 blackpill insist to turn it off.

[jerryneedell]

tested on both Linux and MacOS Catalina -- works for me!

[phrogger]

20191223-21cbd5c.bin restored operation on Windows 10.

[hierophect]

Sorry for being a little late to the party here. Seems like it's just the same VBUS issue the #2379 PR was designed to fix, that just got ahead of our updates for a minute. I've gotten my text fixes in with #2424 and it seems like it's working for everybody again so I think this can be closed.

[hathach]

@hierophect no problems at all, It is Christmas time :)