BlinkyTape not identifying as TTY device on older Macs

baatbaat
in BlinkyTape Troubleshooting

Hi All,

In my quest to repurpose a couple of older Macs to work with BlinkyTape, I'm in a similar situation to BlinkyTape not identifying as TTY device on Linux where the Mac detects the BlinkyTape but doesn't create the TTY. The following is on a PowerPC Mac running OS X 10.5.8 (Leopard).

The Mac equivalent of a Linux lsusb shows:

Bus 027 Device 000: ID 1d50:605e 1d50 BlinkyTape

The dmesg log shows:

       0        0 AppleUSBCDCACMControl: start - Failed to find the CDC driver
AppleUSBCDCACMData: start: InterfaceMappings dictionary not found for this device. Assume CDC Device...
       0        0 AppleUSBCDCACMData: start - Find CDC driver failed

I found the same error for a Microchip MCP2200 controller. Here is some troubleshooting info with way-over-my-head-highly-technical-details on why it isn't working -- MCP2200 not recognized on a mac/OS X and MCP2200 CDC for Mac OS X and Linux.

The solution is described at Serial connection on Mac OS X and [Traumflug/Generation_7_Electronics/USB tool/](https://github.com/Traumflug/Generation_7_Electronics/tree/master/USB tool).

I modified [mcp2200-forwarder.c](https://github.com/Traumflug/Generation_7_Electronics/blob/master/USB tool/mcp2200-forwarder/mcp2200-forwarder.c) lines 49 and 50 to be the hardcoded BlinkyTape USB vendor:product ID's of 1d50:605e. (There are references to ATmega at the above links, and I know the BlinkyTape uses an Atmega 32u4. I'm hoping this means the code is close enough.)

When compiled and run with the highest verbose mode, I get:

$ ./mcp2200-forwarder -vvv -l /tmp/ACM0
device_added()
Device added.
find_interfaces()
Scanning interfaces ...
Interface 0x00001703.
Interface class 2, subclass 2.
Interface has 1 endpoints.
PipeRef 1: direction in, transfer type interrupt, maxPacketSize 16.
Choosing this interface as Interrupt.
Interface 0x00001A03.
Interface class 10, subclass 0.
Interface has 2 endpoints.
PipeRef 1: direction out, transfer type bulk, maxPacketSize 64.
PipeRef 2: direction in, transfer type bulk, maxPacketSize 64.
Choosing this interface as Bulk.
... interface scan done.
send_bridge_setup()
Failed to take down DTE & RTS. Ignoring. (e000404f)
Failed to set baud rate & co. Ignoring. (e000404f)
Failed to raise DTE & RTS. Ignoring. (e000404f)
Unable to set up USB-UART bridge. (e000404f)
close_interface()
device_removed()
pty_open()
Terminal name: /dev/ttys002
Created symlink to /tmp/ACM0

When I start a second shell session and run Oskari Okko Ojala’s Perl Device::BlinkyTape example code pointing to 'dev' => '/tmp/ACM0', it sits there thinking for a few seconds and doesn't send anything to the screen (as expected), not even an error. And, the BlinkyTape just gives me a blank stare :smiley: .

The first shell session running mcp2200-forwarder shows only one new line:

pty_read(), event 0x0002

HERE'S MY QUESTION:

I'm wondering if someone here who is familiar with the BlinkyTape USB hardware could look at [mcp2200-forwarder.c](https://github.com/Traumflug/Generation_7_Electronics/blob/master/USB tool/mcp2200-forwarder/mcp2200-forwarder.c) and tell me if, or what, needs changing? I know enough to change the hardcoded vendor:product ID but that's the limit of what I know about what mcp2200-forwarder.c is doing with the USB code.

If this isn't practical to get going and there's no longer much of a reason for my older Macs to justify their existence and electric bill, I'll quite understand, but I would appreciate knowing either way.

Comments

  • baatbaat

    Well, shoot. How come the Markdown didn't render? :(

  • Matt MetsMatt Mets

    It's a little hard to tell from the source code, but a potential issue is that the BlinkyTape is actually a composite USB device, meaning that it supports a few other interfaces besides TTY-ACM (this was to make it compatible with the default Arduino Leonardo firmware). It looks like that code is trying to automatically figure out what interfaces to use, but I don't quite understand the logic it's using. It's possible that it just needs a little more filtering to only select the interfaces/endpoints associated with the BlinkyTape device

  • Matt MetsMatt Mets

    Ah sorry, i missed the section where it's printing out which interface it is using >.<

    It looks like it is finding the right interfaces, however I'm not sure how to interpret the addresses '0x00001703' or '0x00001A03'.

    For reference, Linux gives me this device configuration for the BlinkyTape:

    $ sudo lsusb -v

    Bus 001 Device 003: ID 1d50:605e OpenMoko, Inc.
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 64
    idVendor 0x1d50 OpenMoko, Inc.
    idProduct 0x605e
    bcdDevice 1.00
    iManufacturer 1 Blinkinlabs
    iProduct 2 BlinkyTape
    iSerial 3
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 75
    bNumInterfaces 2
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
    (Bus Powered)
    Remote Wakeup
    MaxPower 500mA
    Interface Association:
    bLength 8
    bDescriptorType 11
    bFirstInterface 0
    bInterfaceCount 2
    bFunctionClass 2 Communications
    bFunctionSubClass 2 Abstract (modem)
    bFunctionProtocol 1 AT-commands (v.25ter)
    iFunction 0
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 2 Communications
    bInterfaceSubClass 2 Abstract (modem)
    bInterfaceProtocol 0 None
    iInterface 0
    CDC Header:
    bcdCDC 1.10
    CDC Call Management:
    bmCapabilities 0x01
    call management
    bDataInterface 1
    CDC ACM:
    bmCapabilities 0x06
    sends break
    line coding and serial state
    CDC Union:
    bMasterInterface 0
    bSlaveInterface 1
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0010 1x 16 bytes
    bInterval 64
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 1
    bAlternateSetting 0
    bNumEndpoints 2
    bInterfaceClass 10 CDC Data
    bInterfaceSubClass 0 Unused
    bInterfaceProtocol 0
    iInterface 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x02 EP 2 OUT
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0040 1x 64 bytes
    bInterval 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x83 EP 3 IN
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0040 1x 64 bytes
    bInterval 0
    Device Status: 0x0000
    (Bus Powered)

  • baatbaat

    I found an Xcode utility called USB Prober that gives a more detailed dump like your verbose output above. See http://pastebin.com/Br0najQt starting at line 79. Does this help? I don't know what I should be looking for.

  • Matt MetsMatt Mets

    It shows that the computer is seeing the USB device just fine, so I think you're on the right track. I'm unfortunately not sure what would need to be changed to get the driver to work, though :-(

  • baatbaat

    Thanks for the encouragement. :D I'll see if I can contact the author of mcp2200-forwarder.c.

  • baatbaat

    For my tracking purposes, new mcp2200-forwarder issue created at: https://github.com/Traumflug/Generation_7_Electronics/issues/24

Sign In or Register to comment.