Potential Mac M1 (Arm Silicone) issue?

[Alexander-Leon]

I ask this kinda vaguely because I'm not entirely sure if this is a platform issue or an issue with libusb under the hood, but I seem to have an issue specifically on the MAC M1 which I can get the platform to return the structure and provide me all the meta data, but when I stream to/from it. The exchange works once before breaking. Upon inspection of the processed packets being sent out. They're getting malformed as well as no always registering as HID packets. The buffers being passed are seemingly changing as well which leads to be believe it might be an issue with the underlying memory management, but there's so many layers I can't really say for sure.

I'm just not sure if I should be attempting to fix this in the lower levels or if I'm missing something for this to work properly with the wrapper or if this is M1 compatibility issues.

Note: The same project works perfectly on windows and was originally developed on windows, but was meant to be cross-platform.

[Alexander-Leon]

Once I get time. I'll get logs here just to make it obvious what I'm seeing on my end and maybe make it obvious what the issue at hand might be.

[sstallion]

Hi @Alexander-Leon - that sounds strange indeed. FWIW, I use an M1 MBP as my daily driver and I have a couple of small projects to the side that use hid on an M1 without any issues. Since you're using macOS, libusb won't be in the mix - HIDAPI calls into AppKit/IOKit/CoreFoundation directly. As far as I know there haven't been any corruption issues seen so far, but there's always a first time.

Could you describe in a little more detail the calls you're making into package hid? Is there a chance you have a protocol analyzer handy as well to validate the right bits are making their way in and out of the reports?

[Alexander-Leon]

wireshark_usbhid_results.pcapng.zip

Attached is Zipped Wireshark readings.

Code to invoke it.

        err := hid.Init()
	if err != nil {
		t.Fatal(err)
	}

	d, err := hid.OpenFirst(samatmelice.VendorID, samatmelice.ProductID)
	if err != nil {
		t.Fatal(err)
	}
	defer func() {
		_ = d.Close()
		_ = hid.Exit()
	}()

	writeBuf := make([]byte, 512)
	buffer := make([]byte, 512)
	s, err := d.GetMfrStr()
	if err != nil {
		t.Fatal(err)
	}
	t.Logf("%s", s)
	s, err = d.GetProductStr()
	if err != nil {
		t.Fatal(err)
	}
	t.Logf("%s", s)
	writeBuf[0] = 0x0
	writeBuf[1] = 0x0
	writeBuf[2] = 0x3
	_, err = d.Write(writeBuf)
	if err != nil {
		t.Fatal(err)
	}
	t.Logf("Wrote: %d bytes", 512)
	_, err = d.ReadWithTimeout(buffer, time.Second)
	if err != nil {
		t.Fatal(err)
	}

	t.Logf("Read: %d bytes", 512)
	t.Logf("%s", buffer[:])

	writeBuf[0] = 0x0
	writeBuf[1] = 0x0
	writeBuf[2] = 0x1
	_, err = d.Write(writeBuf)
	if err != nil {
		t.Fatal(err)
	}
	t.Logf("Wrote: %d bytes", 512)
	_, err = d.ReadWithTimeout(buffer, time.Second)
	if err != nil {
		t.Fatal(err)
	}

	t.Logf("Read: %d bytes", 512)
	t.Logf("%s", buffer[:])```
	



if there's anything I'm obviously missing I'm all ears, but works just fine on Windows and fails to work on the MBP. (This could potentially be weird driver issues with the ICE,  but other programs seem to be able to interface with 0 issues)

[sstallion]

I suspect what you're running into are differences in the underlying USB implementation. Assuming this is a USB 2.0 HID device, your report length will not exceed 64 bytes. What could be happening is a buffer overflow somewhere either in the bowels of HIDAPI or IOKit.

Backing up a little bit, have you verified the report length for your device? This will be shared as a part of the report descriptor. If you're hardcoding this value, then you'll want to make sure this matches exactly what your device expects.

I also would not recommend treating a buffer as a string in your log function. I've found hex.Dump() output to be very helpful in debugging raw buffers.

For example:

t.Log(hex.Dump(buffer))

[Alexander-Leon]

Hm odd, it is USB 2.0 so I think there's probably something for me to nibble at there

Unless I'm misunderstanding something about the following it should be 512

0x06, 0x00, 0xFF,  // Usage Page (Vendor Defined 0xFF00)
0x09, 0x01,        // Usage (0x01)
0xA1, 0x01,        // Collection (Application)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x96, 0x00, 0x02,  //   Report Count (512)
0x09, 0x01,        //   Usage (0x01)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x96, 0x00, 0x02,  //   Report Count (512)
0x09, 0x01,        //   Usage (0x01)
0x91, 0x02,        //   Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x95, 0x04,        //   Report Count (4)
0x09, 0x01,        //   Usage (0x01)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0xC0,              // End Collection

[sstallion]

Very interesting. Do you have access to a Linux environment? The output of lsusb -v might be valuable.

[sstallion]

It's been quite a while since I've read through the HID spec, but I had forgotten that it is permissible for reports to exceed wMaxPacketSize, so long as they are terminated with a shortened packet. lsbusb -v should give us a better idea of what the device is advertising. I poked around HIDAPI a bit as well and !273 looks eerily similar to what you're seeing.

[Alexander-Leon]

Unfortunately not. Everything I work on linux related is generally containerized

[sstallion]

Gotcha. I wonder if as a next step if it would be worth writing the same test program you have in C and use HIDAPI directly to see if you get different behavior. I can't think of anything in the bindings that could cause the behavior you are seeing. It could be something macOS-specific being triggered by the device you have.

[Alexander-Leon]

That's sorta what I was thinking too. I just figured it'd be worth a shot reaching out to see if you had experienced anything when working on the initial bindings. I was avoiding that route, but at this point seems like the only proper course of action to dig deeper.

[For context I know there's a way to properly interface with it because of openOCD working correctly, I'll just have to dig deeper. Thanks for your feed back though as well as the bindings, they've been useful. ]

[sstallion]

My pleasure and best of luck. I'll close the issue for now, but if you find anything that looks like a smoking gun I'd love to hear back - my curiosity is definitely piqued at this point!