M5StickC usb driver and Catalina



  • 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!


  • @m5stack Cant click that link.



  • @m5stack
    I got this error if I click your link: "Access denied. You do not have permission to access this page."
    Thank you for updating your software.



  • The link worked for me once a few hours ago, but now it’s not.



  • @o-copleston This solution is running perfectly! Thank you!



  • It may make your firmware lose and make it unusable, so if you are willing to take this risk, you can chat with me in private and I will give you a link to download the tool @sheepDog @world101



  • @m5stack Hello, are there any news about a solution for Catalina and M5StickC?



  • @m5stack if you can, please give us the link for a new driver to solve that problem....





  • @m5stack Thank you! The solution 2 (as describe in link) is fully functional.