fix bootloader reenumerate issue in new OSX

[DeqingSun]

DFU_UTIL don't reenumerate successfully in new OSX. So the bootloader will not exit and user need to reset target board.
reenumerate utility from Apple's Prober.app can fix this issue

[rogerclarkmelbourne]

What happens on older OSX systems with this change ?

[DeqingSun]

Don't have an old Mac to test.

I can add -R back. If -R works, bootloader device will not be found and reenumerate will be ignored.
Otherwise reenumerate will be triggered.

[stevstrong]

I don't have any MAC.
Can some MAC user please test this?

[gemyago]

It is possible I'm experiencing this issue. Serial device disappears if I reconnect the board for example, osx reboot will fix it which is obviously not the best solution :). Also, I've noticed that if I attach the device to Win10 running inside of a VirtualBox and then detach it, it will also "restore" the serial device.

I'm not sure how to test this properly, but just running the reenumerate tool makes the device available again:

./tools/macosx/reenumerate -v 0x1eaf,0x0003

If you could point me on a better way to test it, I'll be happy to do it.

[stevstrong]

Have you tried the fix above (link below the first post)?

[gemyago]

So the script I run is following (I have macOS 10.15.4):

./tools/macosx/maple_upload cu.usbmodem14301 2 1EAF:0003 firmware.bin

Following steps:

1. Plug in the board, the serial device is not available (e.g no /dev/cu.usbmodem14301 file present)
2. Run the command above. It fails with error:

Failed to open serial device.
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
dfu-util: Cannot set alternate interface

3. However after running this command for the first time the /dev/cu.usbmodem14301 is now available. So running the command above succeeds:

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download	[=========================] 100%        46040 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
2021-02-22 14:37:50.180 system_profiler[9253:74764] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
2021-02-22 14:37:50.181 system_profiler[9253:74764] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
2021-02-22 14:37:50.181 system_profiler[9253:74764] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
2021-02-22 14:37:50.182 system_profiler[9253:74764] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
2021-02-22 14:37:50.187 system_profiler[9253:74764] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
2021-02-22 14:37:50.187 system_profiler[9253:74764] SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be
Maple 003 bootloader not found
Waiting for /dev/cu.usbmodem14301 serial...Done

So the maple_upload script works, however it looks like it is solving a different issue from the one I'm facing. Also the error Maple 003 bootloader not found is because when the device /dev/cu.usbmodem14301 is attached the osx will show it slightly differently (system_profiler SPUSBDataType | grep -i maple -A 11):

        Maple:

          Product ID: 0x0004
          Vendor ID: 0x1eaf
          Version: 2.00
          Speed: Up to 12 Mb/s
          Manufacturer: LeafLabs
          Location ID: 0x14300000 / 54
          Current Available (mA): 500
          Current Required (mA): 100
          Extra Operating Current (mA): 0

(e.g just Maple but not Maple 003), however after reattaching it, it becomes Maple 003 again.

I started experimenting with a script and found that if the "re-enumerate" block is placed somewhere before:

${DIR}/upload-reset ${dummy_port_fullpath} 750

Then my use case works (e.g plug-in and upload). Also, I had to add a sleep(1) right after reenumerate

[rogerclarkmelbourne]

What board are you using. BluePill etc ?

Because the BluePill relies on the hack of setting one of the USB pins to GPIO then pulsing it low and high, to force re-enumeration of the USB bus, its not guaranteed to work with all OS's or hardware.

It doesn't work on one of the RaspberryPi boards, and various other computers.

This is a fundamental hardware issue with the BluePill type boards.

[gemyago]

What board are you using. BluePill etc ?

STM32F103C8T6. USB resistor is the correct one out of the box (1.5k ohm).

[rogerclarkmelbourne]

Actually, this issue does not even seem to be related to the Arduino core, but is related to the bootloader repo.

[rogerclarkmelbourne]

Doesn't matter what resistor you use. Its still never compatible with all OS's / Hardware.

The only board which is more reliable is the Maple Mini, which uses a separate USB reset control circuit

[gemyago]

Actually, this issue does not even seem to be related to the Arduino core, but is related to the bootloader repo.

very likely yes. However, it helped me to find this reenumerate workaround, without it I was considering getting back to st-link. So even if it's not included in the maple_upload script (which I think would be the right choice), I will still have a way to bring the device back.