M5StickC usb driver and Catalina



  • Hello,
    I worked with a M5Stack, Arduino 1.8.x and MacOS Mojave and every thing with USB was fine.

    I updated to MacOS Catalina and updated Arduino to version 1.8.10. Every with USB for my M5Stack was fine, too. If I check the USB driver I can see:

    $ ls /dev/tty.*
    /dev/tty.Bluetooth-Incoming-Port	
    /dev/tty.SLAB_USBtoUART	
    /dev/tty.usbserial-017D2264
    

    If I like to flash my M5Stick-C and I connected it, I can see only this:

    $ ls /dev/tty.*
    /dev/tty.Bluetooth-Incoming-Port	
    /dev/tty.usbserial-9D5AE08545
    

    With the old and the new Arduino-version the "tty.usbserial-9D5AE08545"-driver did not work. Arduino needs a "SLAB_USBtoUART"-driver.

    What can I do?

    Yes, I know today Catalina is a beta-version, but it will released shortly.



  • What do you mean by does not work the newer gen stick versions only have the number string and work ok but then my OS X is about a year old



  • There known bugs in Catalina.
    Try using the Arduino beta. it "should" work, ...... sometimes. :-(



  • We don't have a Mac with Catalina on in the office to test, so I think it may take a while before our software supports it.



  • @sheepdog

    Catalina unable to drive temporarily. Use VM or BOOTCAMP



  • +1 to this issue. I'm unable to flash to any of my M5StickC's at the moment on Catalina, but can flash to my M5 Camera strangely...



  • Ok, here the fix:

    That did the trick for me



  • Ok sorry I forgot about this until now. If you have an Arduino or an usb to UART adapter you can bypass the inbuilt USB adapter and program M5Stack cores using the UART port



  • No solution with Catalina did work for me. Only the programming with Windows 10 was working.

    Which driver did M5StickC need? A Silicon Labs CP210x-driver?
    I installed CP210x Version 5.2.4 and I used Catalina 10.15.3 (19D49f).



  • As far as I know the esp32 pico, which is inside the stickC does not use the cp210x drivers. Some have reported using standard ftdi drivers to interface with the device. I'm afraid I dont have OS Catalina to test



  • @lukasmaximus Thank you for your help. In the meantime I tested with Catalina Version 10.15.2 (19C57) and with the drivers from FTDI. I can not program the M5StickC, but the Arduino Monitor did work!

    I found the problem: The M5StickC didn't change to upload mode!
    I connected a small button between GND and G0 at the 8-ext Pin connector and I pressed the button if Arduino like to upload ("Connecting........_____...."). The workaround worked fine.



  • Is there any other way to change M5StickC to upload-mode? Ist isn‘t nice to change the connector every time I like to upload a new program. I used a joystick-modul and my upload-modul.



  • I can confirm that the workaround "Connect G0 pin to GND" works for me on Catalina 10.15.2. I am now able to write to the m5StickC wheras before it was stuck connecting eventually throwing the error "A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header". I am able to reproduce this on two m5StickCs. It's worth noting this is without any 3rd party drivers and after only following the steps given here - https://docs.m5stack.com/#/en/quick_start/m5stickc/m5stickc_quick_start_with_arduino_MacOS

    Has there been any progress on resolving the issue?



  • In the meantime I tested three M5StickC and can not program anyone without "Connect G0 pin to GND". I changed from Arduino to esp-idf and got the same issue.

    After some analysis, I separated the problem: I think the esptool.py didn't work correct with the cp210x drivers. The critical part is:

      def _connect_attempt(self, mode='default_reset', esp32r0_delay=False):
        """ A single connection attempt, with esp32r0 workaround options """
        # esp32r0_delay is a workaround for bugs with the most common auto reset
        # circuit and Windows, if the EN pin on the dev board does not have
        # enough capacitance.
        #
        # Newer dev boards shouldn't have this problem (higher value capacitor
        # on the EN pin), and ESP32 revision 1 can't use this workaround as it
        # relies on a silicon bug.
        #
        # Details: https://github.com/espressif/esptool/issues/136
        last_error = None
    
        # If we're doing no_sync, we're likely communicating as a pass through
        # with an intermediate device to the ESP32
        if mode == "no_reset_no_sync":
            return last_error
    
        # issue reset-to-bootloader:
        # RTS = either CH_PD/EN or nRESET (both active low = chip in reset
        # DTR = GPIO0 (active low = boot to flasher)
        #
        # DTR & RTS are active low signals,
        # ie True = pin @ 0V, False = pin @ VCC.
        if mode != 'no_reset':
            self._setDTR(False)  # IO0=HIGH
            self._setRTS(True)   # EN=LOW, chip in reset
            time.sleep(0.1)
            if esp32r0_delay:
                # Some chips are more likely to trigger the esp32r0
                # watchdog reset silicon bug if they're held with EN=LOW
                # for a longer period
                time.sleep(1.2)
            self._setDTR(True)   # IO0=LOW
            self._setRTS(False)  # EN=HIGH, chip out of reset
            if esp32r0_delay:
                # Sleep longer after reset.
                # This workaround only works on revision 0 ESP32 chips,
                # it exploits a silicon bug spurious watchdog reset.
                time.sleep(0.4)  # allow watchdog reset to occur
            time.sleep(0.05)
            self._setDTR(False)  # IO0=HIGH, done
    
        for _ in range(5):
            try:
                self.flush_input()
                self._port.flushOutput()
                self.sync()
                return None
            except FatalError as e:
                if esp32r0_delay:
                    print('_', end='')
                else:
                    print('.', end='')
                sys.stdout.flush()
                time.sleep(0.05)
                last_error = e
        return last_error
    
    def connect(self, mode='default_reset'):
        """ Try connecting repeatedly until successful, or giving up """
        print('Connecting...', end='')
        sys.stdout.flush()
        last_error = None
    
        try:
            for _ in range(7):
                last_error = self._connect_attempt(mode=mode, esp32r0_delay=False)
                if last_error is None:
                    return
                last_error = self._connect_attempt(mode=mode, esp32r0_delay=True)
                if last_error is None:
                    return
        finally:
            print('')  # end 'Connecting...' line
        raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
    

    The esptool.py used reset with DTR and RTS and I suspect this part did not work correct, because any print of '.' or '_' showed a (fatal) error.

    My short test for all existing ports showed the error:
    $IDF_PATH/components/esptool_py/esptool/esptool.py chip_id



  • @sheepdog this problem from MAC OS FTDI driver , you can try to use WIN10 OS (like using a virtual machine) to upload program. also M5StickC Upload program don't need CP2104 Driver.



  • @m5stack Thank you for your quick response. I am sure that Mac OS Catalina need a driver. A few days ago I installed Mac OS 10.15.2 form scratch and M5StickC needs the cp210x-driver (M5Stack needs the FTDI driver!).

    You can test it. If you connect a M5StickC you see at the directory /dev a file with this name "cu.usbserial-<number>". With connected M5Stack you see "cu.SLAB_USBtoUART" (<- This is the FTDI driver).

    My workaround is "Connect G0 pin to GND". That is not nice. Your solution to start a VM is even more complex because all need all my files there.

    Yes, I can program M5StickC, but I am looking for an easy way to program M5StickC with short turn around times and easy handling. Normally I used Atom editor with PlatformIO.



  • @m5stack could you please advise on the best process for getting M5StickC to work and flash via esptool on Mac OS Catalina ?

    Also, advise on which driver is needed for M5StickC. Is it the FTDI driver or is it the CP210X driver ?



  • @tcruse first , on some Mac PC, M5StickC cannot upload program properly.

    the solution: When programming, short the G0 to GND using the DuPont line.

    and , all most PC don't need driver with M5StickC. But some old PC System need install FTDI driver.

    FTDI driver is for M5StickC, CP2104 driver is for M5Stack Core ( like Fire BASIC M5GO)



  • @m5stack Yes, I swapped the drivers. You can check it at Apple menu, systemreport and USB.

    1. If I connected a M5Stack I saw:
      0_1577975601066_M5Stack.jpg

    2. If I connected a M5StickC I saw:
      0_1577975705966_M5StickC.jpg

    You can check the loaded drivers and their versions in terminal with "sudo kextstat".

    I noticed that sometimes M5Stack didn't not work without "short the G0 to GND". I think that is a timing-problem at Catalina and esptool.py. It is not a problem of M5Stack- or M5StickC-Software.



  • I formulated an Issue at Github: Link to Issue

    Supplement on January 18, 2020: You need an Espressif account to see the issue.



  • This post is deleted!