You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On macOS (observed: macOS 15 / Darwin 25.5.0, Apple Silicon), HidSharp 2.6.4's DeviceList.Local.GetHidDevices() returns 0 devices, even when a target HID device is physically present and enumerable via the OS. This makes HidLibraryDeviceEnumerator / HidLibraryTransport unable to find the PIC32 HID bootloader, so FirmwareUpdateService.UpdateFirmwareAsync fails at WaitingForBootloader and the PIC32 firmware-update flow cannot run on macOS at all.
Evidence
With a DAQiFi Nq1 in HID bootloader mode (after SYSTem:FORceBoot):
Opening the specific device with IOHIDDeviceOpen returns kIOReturnSuccess (0x0) as a normal (non-root) user — so this is not a TCC/Input-Monitoring permission wall for vendor HID devices; it's a HidSharp-layer problem. (IOHIDManagerOpen against all devices does return 0xE00002E2 not-permitted, because matching everything includes keyboards, but per-device open of the bootloader is fine.)
A native IOKit probe (IOHIDDeviceSetReport / input-report callback) successfully drove the bootloader: READ_BOOT_INFO returned version 1.4 and READ_CRC returned correct CRCs — proving the device and the wire protocol work; only HidSharp's enumeration is broken here.
Impact
PIC32 (application) firmware update over USB is non-functional on macOS via the current stack. The desktop app runs on Windows where HidSharp works, so this hasn't been a release blocker, but it blocks macOS bench testing / any macOS consumer.
WiFi-module update (external process) and all serial/TCP streaming are unaffected.
Suggested directions
Evaluate upgrading/replacing HidSharp (2.6.4 dates to ~2021; macOS 15/ARM may be unsupported), or
Add a native IOKit-backed IHidPlatform implementation for macOS (the enumerator already abstracts the platform behind IHidPlatform, so a macOS adapter slots in cleanly). A working native IOKit read/write path was prototyped during feat: Use bootloader READ_CRC for real firmware verification #213 bench testing.
Context
Found while bench-testing the READ_CRC verification from #213 against real hardware. The CRC feature itself was validated on-device via a native IOKit probe (see daqifi-core#261).
Summary
On macOS (observed: macOS 15 / Darwin 25.5.0, Apple Silicon),
HidSharp2.6.4'sDeviceList.Local.GetHidDevices()returns 0 devices, even when a target HID device is physically present and enumerable via the OS. This makesHidLibraryDeviceEnumerator/HidLibraryTransportunable to find the PIC32 HID bootloader, soFirmwareUpdateService.UpdateFirmwareAsyncfails atWaitingForBootloaderand the PIC32 firmware-update flow cannot run on macOS at all.Evidence
With a DAQiFi Nq1 in HID bootloader mode (after
SYSTem:FORceBoot):DeviceList.Local.GetHidDevices()):HID devices visible: 0.IOHIDManagerCopyDevices): 18 devices listed, including the bootloader:VID=0x04D8 PID=0x003C in=64 out=64 'USB HID Bootloader'.ioreg -p IOUSBconfirms the device:idVendor=1240 (0x04D8),idProduct=60 (0x003C), "USB HID Bootloader".IOHIDDeviceOpenreturnskIOReturnSuccess(0x0) as a normal (non-root) user — so this is not a TCC/Input-Monitoring permission wall for vendor HID devices; it's a HidSharp-layer problem. (IOHIDManagerOpenagainst all devices does return0xE00002E2not-permitted, because matching everything includes keyboards, but per-device open of the bootloader is fine.)A native IOKit probe (
IOHIDDeviceSetReport/ input-report callback) successfully drove the bootloader: READ_BOOT_INFO returned version 1.4 and READ_CRC returned correct CRCs — proving the device and the wire protocol work; only HidSharp's enumeration is broken here.Impact
Suggested directions
IHidPlatformimplementation for macOS (the enumerator already abstracts the platform behindIHidPlatform, so a macOS adapter slots in cleanly). A working native IOKit read/write path was prototyped during feat: Use bootloader READ_CRC for real firmware verification #213 bench testing.Context
Found while bench-testing the READ_CRC verification from #213 against real hardware. The CRC feature itself was validated on-device via a native IOKit probe (see daqifi-core#261).