Logic software in Mac M4 doesn't detect logic 8 device

Support
1

The device report shows “Unnamed Device”

Unnamed Device:

Location ID: 0x01100000

Connection Type: Removable

Serial Number: Not Provided

Link Speed: 480 Mb/s

USB Vendor ID: 0x21a9

USB Product ID: 0x1000

USB Product Version: 0x0000

2

@jose.padron We’ll take care of this for you! It looks like a potentially failed unit (specifically, the EEPROM looks like it went bad). I sent you an email just now. Let’s chat there.

3

The device works fine on a Windows PC and an Intel-based Mac. However, it does not work on my new Apple Silicon Mac.

4

ioreg -p IOUSB -l -w 0

     | | +-o IOUSBHostDevice@20233100  <class IOUSBHostDevice, id 0x100151c9f, registered, matched, active, busy 0 (9 ms), retain 24>

      | |     {

      | |       "sessionID" = 12310145430205

      | |       "USBSpeed" = 3

      | |       "idProduct" = 4096

      | |       "iManufacturer" = 0

      | |       "bDeviceClass" = 255

      | |       "IOPowerManagement" = {"PowerOverrideOn"=Yes,"DevicePowerState"=2,"CurrentPowerState"=2,"CapabilityFlags"=32768,"MaxPowerState"=2,"DriverPowerState"=0}

      | |       "bcdDevice" = 0

      | |       "bMaxPacketSize0" = 64

      | |       "iProduct" = 0

      | |       "iSerialNumber" = 0

      | |       "bNumConfigurations" = 1

      | |       "UsbDeviceSignature" = <a92100100000ffffffffffff>

      | |       "USB Address" = 24

      | |       "locationID" = 539177216

      | |       "bDeviceSubClass" = 255

      | |       "bcdUSB" = 512

      | |       "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}

      | |       "bDeviceProtocol" = 255

      | |       "USBPortType" = 0

      | |       "IOServiceDEXTEntitlements" = (("com.apple.developer.driverkit.transport.usb"))

      | |       "Device Speed" = 2

      | |       "idVendor" = 8617

      | |       "kUSBAddress" = 24

      | |     }

From Copilot:

:white_check_mark: Summary of the issue

You have a USB device that:

  • :white_check_mark: Works on Windows and Intel-based Macs

  • :cross_mark: Does not work properly on Apple Silicon (ARM) Macs

:magnifying_glass_tilted_left: Root cause

From your ioreg output:

  • iManufacturer = 0

  • iProduct = 0

  • iSerialNumber = 0

  • bDeviceClass = 255 (vendor-specific)

:backhand_index_pointing_right: This means:

  1. The device does not provide any readable identity

    • No name

    • No manufacturer

    • No serial number

  2. It uses a vendor-specific USB class

    • No standard macOS driver applies

    • macOS doesn’t know how to “treat” it

:warning: Why it fails on Apple Silicon

  • New macOS (especially on ARM) has a stricter USB stack

  • Legacy behaviors (used on Intel Macs / Windows) are gone

  • No fallback naming or automatic driver binding

:backhand_index_pointing_right: Result:

  • Shows as “Unnamed Device”

  • No system interface is created (/dev, HID, etc.)

  • Other apps cannot use it automatically

5

The issue is still present in my MAC :frowning: I had to use a window computer with the device. Is there a way to update the software for the logic 8 device?

6

I didn’t check for a support ticket between Jose and Saleae, but When Tim said the EEPROM looks like it went bad, it’s because the USB Product ID is supposed to be 0x1004, not 0x1000. 0x1000 is not actually a valid PID for a Saleae device.

We see the occasional EEPROM failure, and the best solution is to just get the unit replaced through an RMA request to support. It could be re-programmed, but who knows how long that’s going to last, and we don’t provide a tool to easily do that.

If it only fails on one machine, my first guess is that the EEPROM is starting to fail, and that computer has a slightly lower USB voltage, or more noise. I would try disconnecting it and reconnecting it over and over to see if that changes anything. Also, if you did a “have disk” driver install on windows recently, that actually lets you bypass this issue by force-associating our driver with the device regardless of the incorrect PID. This isn’t possible on MacOS.

A bit of background: Logic 8 does not have any persistent memory. It has a hardware bootloader (part of the USB controller IC we use) that reads 8 bytes of data from EEPROM, and in those 8 bytes are our VID and PID. It then attaches to the system with that identification.

Our software detects it and notices that it’s not yet running our firmware. It downloads our firmware to RAM, and reboots the device. The device-reconnects using the VID & PID contained in our firmware image, which is RAM, and not read from the EEPROM. (The VID & PID in the firmware image are the same as the ones in the EEPROM)

However you can’t get to the second part if the EEPROM VID & PID are not correct.

7

Well, could be the EEPROM as you say. But, the AI notes posted have something that is certainly true: newer MacOS on ARM is EXTREMELY picky about the USB standard. A lot of newer macs have only USB-C ports. This is a problem as USB-C wants to see the CC pins be properly handled. These pins did not exist for USB-A / USB-B cabling. Even USB3 over non-USBC cabling does not have CC pins. This is a problem as an ARM Mac with MacOS26 requires CC pins to be wired up in order to accept things on the USB-C ports. It will not fall back to USB2 or anything. It just doesn’t work. Getting a cheap USB-C to multi-USB A dongle doesn’t always work either because a lot of those don’t handle the CC pins and have the same problem. You need an X in 1 device with ethernet/sdcard/hdmi and such. Those are forced to handle CC pins because of all the stuff they do. At least, there’s a better chance they handle it. My Windows / Linux PC has no such problem. Not only does it have USB3-A ports, but it also is fine with a 4 port USB hub.

TL;DR - MacOS wants to see the CC pins be connected if you are using USB-C ports. It sucks.

8

Hi Collin!

Just to add here - USB PD is only involved in the negotiation of voltage / current. For all non-USB-C devices, the USB cable (a C-to-micro B, or in our case a C-to-SuperSpeed micro B) includes a resistor on one of the CC pins to indicate that it’s requesting power. Without that, the host port won’t provide power at all, and the device won’t power on. A USB C-to-A adapter (C side upstream, A side downstream) will contain this resistor too.

As soon as our device has power, it can begin USB enumeration with the host over plain old USB 2.

Things get much more interesting when you’re using USB-C on both ends. Low power devices can get away with a simple resistor to get 5V with low current, but if you want to, for example, charge a USB battery bank, PD will start with the default 5V but then use bi-directional communication to negotiate a higher voltage and/or current.

Things get really interesting with devices like cell phones and laptops that support fast-role swap, where the power provider (source) and consumer (sink) can swap - e.g. if you have a USB-C docking station that’s connected to wall power, a laptop, and some USB devices. It starts out charging your laptop, but if you unplug the wall charger, fast-role swap will allow the laptop and the docking station will swap jobs in less than 150us, and the laptop will take over powering the docking station and the attached devices - hopefully fast enough for nothing to notice.

Anyway, USB PD isn’t the problem here. Also, this isn’t a USB spec compliance issue either. The Logic 8 is getting old and is starting to forget it’s own address. Our software scans for and connects to our devices by matching exactly on both the VID and PID of the USB identification, so if that’s off by even 1 bit, our software will ignore the device.