Apple Silicon M1 Chip not Connecting

Hello,
I have a problem flashing software using my MacBook Pro with Apple M1 Chip.
After compiling the code, when trying to upload it, it just keeps connecting no matter what I press on the esp32 dev board. I checked multiple ones, same problem.
I use this driver: CP210x USB to UART Bridge VCP Drivers - Silicon Labs

That’s all I get.
Some people seem to be able to upload code just fine, I really don’t get what’s the problem here.

That you very much for every answer,
Johannes

Maybe the SiLabs driver is a problem with M1.

Yeah, but I thought I ruled that out by successfully testing the serial monitor.
I used that driver on my old MacBook without any problems, and I have not found any other working drivers so far - maybe I just searched for the wrong stuff? I searched for “usb uart driver mac”, and this one was pretty much the only one showing up not looking kinda sketchy.

I don’t have an Apple Silicon Mac to test it. But macOS comes with Apple drivers for the SiLabs chips out of the box. You can check it with:

ls -l /System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBSLCOM.dext

If the command shows a few files, you have the Apple drivers.

Then again, Silicon Labs have updated their drivers to use the new user-mode DriverKit extensions instead of the old kernel extensions. If not, you probably wouldn’t have been able to install them on a Apple Silicon Mac anyway.

You can try to uninstall the drivers. For the latest drivers, it’s very simple. Just move CP210xVCPDriver from the Applications folder to the trash.

Whether the Apple or the SiLabs drivers are used can be derived from the device name:

  • /dev/cu.SLAB_USBtoUART: SiLabs drivers
  • /dev/cu.usbserial-0001: Apple drivers

I can’t promise you the Apple drivers will make a difference though.

1 Like

Tank you SO MUCH.
I tested the Apple Driver, serial monitor and uploading software works.
Seems to be a problem with the silicon labs driver.

Just needed to change the Environment Variable in .zshenv.

I’m glad it works. Possibly the two drivers were fighting for the same device, rendering /dev/cu.SLAB_USBtoUART unsuable.