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

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

1. If I connected a M5Stack I saw:
   

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

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)

Also, advise on which driver is needed for M5StickC. Is it the FTDI driver or is it the CP210X 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.

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

Has there been any progress on resolving the issue?

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.

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

• Use the latest CP210x USB to UART driver
• Connect G0 pin to GND

That did the trick for me