M5StickC usb driver and Catalina

sheepDog

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.

flippycurb

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?

sheepDog

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

m5stack

@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.

sheepDog

@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.

tcruse

@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 ?

m5stack

@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)

sheepDog

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

If I connected a M5Stack I saw:
If I connected a M5StickC I saw:

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.

sheepDog

I formulated an Issue at Github: Link to Issue

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

m5stack

This post is deleted!

diogovaraujo

@m5stack Cant click that link.

sheepDog

@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.

world101

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

nsfilho

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

m5stack

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

sheepDog

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

nsfilho

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

m5stack

@nsfilho @sheepDog Please read the information carefully before using the tool

link:
http://community.m5stack.com/topic/1591/m5stickc-and-atom-on-macos-platform-can-t-upload-programs-solustion

nsfilho

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