Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trouble enumerating nRF52840-mdk-dongle on macOS #34

Open
fabianfreyer opened this issue Nov 10, 2020 · 4 comments
Open

Trouble enumerating nRF52840-mdk-dongle on macOS #34

fabianfreyer opened this issue Nov 10, 2020 · 4 comments

Comments

@fabianfreyer
Copy link

hf2 is unable to flash an nRF52840-mdk-dongle on macOS. Even though the device is plugged in and in bootloader mode, hf2 (and cargo-hf2) both fail to interact with it:

thread 'main' panicked at 'Are you sure device is plugged in and in bootloader mode?', hf2-cli/src/main.rs:36:16
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The device's vendor and product ID are 0x239a:0x0029, and it is shown correctly in System Information.app:
image

I've debugged it to the point that doesn't seem like hidapi's hid_enumerate enumerates this device properly. hid_enumerate uses IOKit to enumerate devices using IOHIDManagerSetDeviceMatching. OTOH, bobbin, which correctly identifies the USB device (but incorrectly tries to flash it using BOSSA) uses [IO Registry] on macOS and sysfs on linux (source):

$ bobbin list
ID        VID:PID  Vendor / Product                         Serial Number           
831c5efe 239a:0029 MakerDiary / nRF52840 MDK USB Dongle     1F52AB7702F5F88E

I assume that the reason the dongle appears in the IO Registry, but not in IOKit's IOHIDManagerSetDeviceMatching, is because it reports a device class of 0xef (miscellaneous) instead of 0x3:

image

I wonder what the right way forward is here - is this a bug in the bootloader on the nRF52840-mdk-dongle / hidapi / hf2-rs? Would it make sense to import the ioreg code from bobbin?

@jacobrosenthal
Copy link
Owner

I wasnt aware they were shipping an hf2 bootloader. I know adafruit has a nordic uf2 but no idea what its shipping on.

Yeah seems like it might be this one
https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/d6b28e66053eea467166f44875e3c7ec741cb471/src/boards/mdk_nrf52840_dongle/board.h

Also does it at least come up as a flash drive? can you do the usual copy a uf2 file over? As always make sure you update their bootloader to their latest whatever their latest is.

https://github.com/makerdiary/nrf52840-mdk-usb-dongle/blob/f23887c4b96c0a8212f198001387a1434a16492c/firmware/uf2_bootloader/README.md

Of course make sure youre enable debug logs with RUST_LOG=debug cargo hf2 ... or whatever. Though if you don't think its enumerated im not sure what well see

As always, whats your hf2 version and make sure to update to latest. Do you have any other adafruit stuff? Might be worth seeing if one of those enumerates.

You can also just get something on it in general with cargo objcopy and either thier uf2 python tool or theres a rust one called uf2conv. From looking at those docs it would be something like this from inside a rust project with a blinky_basic example

cargo install uf2conv
cargo install cargo-binutils
rustup component add llvm-tools-preview
cargo objcopy --release --example blinky_basic -- -O binary blinky_basic.bin
uf2conv blinky_basic.bin --base 0x26000 --family 0xADA52840 --output blinky_basic.uf2

@fabianfreyer
Copy link
Author

I wasnt aware they were shipping an hf2 bootloader. I know adafruit has a nordic uf2 but no idea what its shipping on.

Yeah seems like it might be this one
https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/d6b28e66053eea467166f44875e3c7ec741cb471/src/boards/mdk_nrf52840_dongle/board.h
yes, exactly.

Also does it at least come up as a flash drive? can you do the usual copy a uf2 file over? As always make sure you update their bootloader to their latest whatever their latest is.
Yeah, it does, and copying a uf2 file over does work (for some uf2 files, I haven't been able to get a working rust one yet)

https://github.com/makerdiary/nrf52840-mdk-usb-dongle/blob/f23887c4b96c0a8212f198001387a1434a16492c/firmware/uf2_bootloader/README.md

Of course make sure youre enable debug logs with RUST_LOG=debug cargo hf2 ... or whatever. Though if you don't think its enumerated im not sure what well see
Yeah, I sprinkled a few println! statements throughout the source when enumerating, so I'm pretty sure it's not enumerated.

As always, whats your hf2 version and make sure to update to latest. Do you have any other adafruit stuff? Might be worth seeing if one of those enumerates.

I was on the latest commit on master.

You can also just get something on it in general with cargo objcopy and either thier uf2 python tool or theres a rust one called uf2conv. From looking at those docs it would be something like this from inside a rust project with a blinky_basic example

cargo install uf2conv
cargo install cargo-binutils
rustup component add llvm-tools-preview
cargo objcopy --release --example blinky_basic -- -O binary blinky_basic.bin
uf2conv blinky_basic.bin --base 0x26000 --family 0xADA52840 --output blinky_basic.uf2

Thanks! I'll try to get something like that to work, but no dice so far. I was hoping a bit to be able to use hf's ELF logic to flash, since I have a bit of a bad feeling that it's the objcopy that's messing some things up.

@jkelleyrtp
Copy link

jkelleyrtp commented Nov 18, 2020

I'm having the same issues - NRF52840 Express, macOS 15.7. I've got uf2conv working for very simple programs, but not working when I enable more features and dependencies. I assume the memory layout might be wrong.

When I put on the "wrong" programs the Express flashes red and the bootloader signal is a solid red. Any thoughts how I should go about debugging hf2 and seeing if I can get it to enumerate?

In the enumeration phase, here's what's being returned:

There are 19 devices connected
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8103, vid: 0x5ac, mfid: "Apple"
Device as hex is pid: 0xc62c, vid: 0x46d, mfid: "3Dconnexion"
Device as hex is pid: 0x8102, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8102, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8600, vid: 0x5ac, mfid: ""
Device as hex is pid: 0x8104, vid: 0x5ac, mfid: "Apple"
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8302, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8302, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8302, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x8262, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x340, vid: 0x5ac, mfid: "Apple Inc."
Device as hex is pid: 0x06, vid: 0x1000, mfid: "Unknown"

All the VIDs are wrong - is it an Apple/permissions thing?


I've opened an issue on hidapi. I'm testing the hidapi library with python and getting the same issue.

libusb/hidapi#211

@jacobrosenthal
Copy link
Owner

Did you all come to any conclusions on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants