Open qlister opened 2 weeks ago
We test every commit we make on (among others) an nRF52-DK. Can you tell us some more details about your particular board?
And now the log file :-)
It is just a regular nrf52-DK board - fresh out of it's antistatic bag. I am using a Chromebook if that makes a difference?
First up, it seems you don't give any --chip
arguments to the command. We currently can't auto-detect nRF chips, so probe-rs wouldn't work anyway with just probe-rs erase -r
.
Second, what version and what model number is that board? Maybe you got a new one that behaves differently.
good call on the 'chip'
Still no joy.. Here is the output
quentinlister@penguin:~/rust/nrf1$ probe-rs erase --chip nrf52832_xxAA WARN probe_rs::probe::jlink: vendor-specific interface with 1 endpoints, expected 2 (skipping interface) Error: Failed to open the debug probe.
Caused by: 0: An error which is specific to the debug probe in use occurred. 1: found multiple matching USB interfaces (1 and 2) quentinlister@penguin:~/rust/nrf1$
The PCB has a label
Great, thanks. Do you have the option to try and check if https://github.com/probe-rs/probe-rs/pull/2569 resolves your problem?
I will try this - but it will have to be tomorrow. The family is closing down for the night! Thanks for the support so far.
OK, so I have compiled a release version of your jlink branch and run it.
This is what i get now: quentinlister@penguin:~/rust/probe-rs/target/release$ ./probe-rs erase --chip nrf52832_xxAA Error: Failed to open the debug probe.
Caused by: 0: An error which is specific to the debug probe in use occurred. 1: found multiple matching USB interfaces (1 and 3) quentinlister@penguin:~/rust/probe-rs/target/release$
The list of USB devices is: quentinlister@penguin:~/rust/probe-rs/target/release$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 1366:1051 SEGGER J-Link Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub quentinlister@penguin:~/rust/probe-rs/target/release$
If I disconnect and then reconnect the nrf52-DK board, the first time I run the erase I get: quentinlister@penguin:~/rust/probe-rs/target/release$ ./probe-rs erase --chip nrf52832_xxAA Error: Failed to open the debug probe.
Caused by: 0: USB Communication Error 1: error while opening the USB device: No such file or directory (os error 2) quentinlister@penguin:~/rust/probe-rs/target/release$
I am doing an erase as I figured this was the simplest operation....
Best regards
Q
The operation you're attempting makes no difference, we bail with an error way before that. The 1: found multiple matching USB interfaces (1 and 3)
error is... well, more interesting. I have absolutely no idea why your board thinks it has two debug interfaces or if that is intended by segger at all, or a side-effect of using a chromebook.
Can you please provide logs? At least that should have some details about the second interface.
Using this command: ./probe-rs erase --chip nrf52832_xxAA --log-file log.txt log.txt
log file is attached
Also, possibly of note:
quentinlister@penguin:~/rust/probe-rs/target/release$ ./probe-rs list The following debug probes were found: [0]: J-Link -- 1366:1051:001050354599 (J-Link) quentinlister@penguin:~/rust/probe-rs/target/release$
@Tiwalun do you happen to have an idea here? This particular j-link seems to have a double for every interface. Is this a recent change on the dev board/j-link firmware, or is this a host-side bug?
Not a clue! I am a noob to Rust. I can try to debug, but it will take me forever :-)
@Tiwalun do you happen to have an idea here? This particular j-link seems to have a double for every interface. Is this a recent change on the dev board/j-link firmware, or is this a host-side bug?
I'm not aware of any changes, but Segger decides that in the end.
@qlister Do you have the J-Link tools from Segger installed? Available here: https://www.segger.com/downloads/jlink/ Does the DK work if you use any of the tools from there?
Hmm first it said (1 of 2) and then (1 of 3) ... sounds oddly inconsistent.
Hmm first it said (1 of 2) and then (1 of 3) ... sounds oddly inconsistent.
It's not, before my PR it stopped at the second interface with the Interrupt endpoint. Applying the PR skipped that and failed at the next interface.
My working DK, also version 3.0.0, has the following descriptors:
lsusb -v -d 1366:1051
Bus 001 Device 018: ID 1366:1051 SEGGER J-Link
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1366 SEGGER
idProduct 0x1051
bcdDevice 1.00
iManufacturer 1 SEGGER
iProduct 2 J-Link
iSerial 3 001050371079
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x00bb
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 4 Configuration
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0
iFunction 5 CDC
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 5 CDC
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
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 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 6 CDC DATA interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0
iFunction 7 CDC
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 7 CDC
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 3
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 2
bSlaveInterface 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 8 CDC DATA interface
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 1
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 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 9 BULK interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 10 MSD interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
And Segger says this about the version:
Product = J-Link OB-nRF5340-NordicSemi V1.00
Nickname =
SN = 1050371079
USB = SN 1050371079
HostFW = 2023 Oct 30 12:13
EmuFW = 2023 Oct 30 12:13
The descriptors from my -DK are different from yours: I haven't tried connecting it to the Nordic toolchain yet - perhaps this does some updating / configuration? Or perhaps I have a faulty unit....!!!!
Bus 001 Device 010: ID 1366:1051 SEGGER J-Link
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1366 SEGGER
idProduct 0x1051
bcdDevice 1.00
iManufacturer 1 SEGGER
iProduct 2 J-Link
iSerial 3 001050354599
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x00bb
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 4 Configuration
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0
iFunction 5 CDC
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 5 CDC
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 03 01
** UNRECOGNIZED: 04 24 02 06
** UNRECOGNIZED: 05 24 06 00 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 6 CDC DATA interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0
iFunction 7 CDC
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 7 CDC
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 03 03
** UNRECOGNIZED: 04 24 02 06
** UNRECOGNIZED: 05 24 06 02 03
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 8 CDC DATA interface
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 1
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 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 9 BULK interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 10 MSD interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
You don't need any tools from nordic, but if you install the tools from Segger from https://www.segger.com/downloads/jlink/ then you can try to update the firmware of the J-Link on the DK. That might help.
You can use the J-Link Configurator, that can show you the version of the J-Link firmware, and also update it.
I've updated #2569 with a workaround that might help, if you could please retest @qlister
I think my problem is more fundamental As suggested by @Tiwalun , I have loaded the Segger J-Link configurator - the board isn't detected:
Also, the Nordic Semi desktop stuff - can see the board - but has an ominous message of: Not supported yet
I think that this is a 'me' problem. My apologies for taking your time to look at this.
I will get a replacement board - and also request some support from the Nordic help desk.
I will let you know on this thread when I have a working board - and then let you know if the rs-probe works as it should.
Thanks again
Q
Please try #2569 once more, I'd love to see if we can do anything with this device as it is. If all other bits are in place except for the class/subclass/protocol info, we might still be able to work with the board.
OK. re-built rs-probe - we have a new error...
WARN probe_rs::vendor::nordicsemi::sequences::nrf52: Core is locked. Erase procedure will be started to unlock it. Error: Connecting to the chip was unsuccessful.
Caused by: 0: An ARM specific error occurred. 1: An operation could not be performed because it lacked the permission to do so: erase_all. quentinlister@penguin:~/rust/probe-rs/target/release$
Please try #2569 once more, I'd love to see if we can do anything with this device as it is. If all other bits are in place except for the class/subclass/protocol info, we might still be able to work with the board.
Even if it works with this, I would still prefer to not having more workarounds in the code. And now you just end up with a board which only works with probe-rs, but not with any other tools.
And now you just end up with a board which only works with probe-rs, but not with any other tools.
While not ideal, I would consider this workaround better than just throwing a potentially working-ish board away generating e-waste.
OK, being dumb here - is this working now?
I'm not convinced the board is actually broken, one usb cable and one machine is not enough variety in hardware for me.
@qlister Do you have the possibility to test with another machine, or another USB cable?
The fix from @bugadani seems to make it work for your board, but it will probably not work with any other tools in this state.
OK, being dumb here - is this working now?
To clarify, the error about the protection is expected. The nRF52 chips have a feature where they enable ap proect automatically, if it's not disabled by firmware. And this means that debugger access is blocked. Passing --allow-erase-all
will unlock it, and allow you to program it.
While not ideal, I would consider this workaround better than just throwing a potentially working-ish board away generating e-waste.
I'm no fan of generating e-waste, but having one special DK in the world is also not helping.
OK. I have my Chromebook where I have been running rs-probe building and testing. I couldn't face the aggro of trying this on Win10! I have tried 2 USB cables - one of which is my usual 'debugging' cable that I use with an ST-Link on other projects. The nordic stuff has been tested on my Windows 10 box.
I do agree - I think that the hardware is probably OK. There will be some software niggle - probably in the firmware that is on the nrf52-DK that I have received.
I have some target hardware that I need to develop some extremely basic firmware for that uses an nrf52832 - which is why I got the DK board.
Incidentally, I got rs-probe working with a micro-bit on my Chromebook, but I can't get at the pins I need for my application
Thanks for checking.
If you want to get the debugger on the board working as intended, so that the Nordic or Segger tools work, it's probably best to open a case on https://devzone.nordicsemi.com/ and mention the issue you're seeing on Windows with the Nordic tools.
If you're fine with the board just being useable under probe-rs, then the fix by @bugadani works.
Excellent! Thanks very much for your help here.
I will let you know what comes back from Nordic.
It seems like I have managed to erase the target chip as the demo code is no longer running.
Thanks again for your amazing help
Q
A bit of a follow-up to this one.
I got a response from the NordicDevZone about the issues I had with the Segger tools. I was advised to install the legacy USB driver.
I did this - on the Windows 10 box
When operating the tools, an update was performed on the interface chip (dated April 24). After that, the Nordic tools started working - (although I do still get the 'Not Supported Yet' on the Quick Start app)
After this update - Probe-RS on my Acer Spin-513 Chromebook still would not function with the nrf52-DK - same error as before. - sad times :-(
FINALLY - I cranked up a Raspberry Pi and installed the rust toolchain. Hey-presto. Probe-RS can now see the nrf52-DK and I can flash code.
I have a flashing LED!!!!!! I am SO happy :-)
Thanks once again!
I'm struggling here!
I have the nRF52-DK which has an inbuilt SEGGER interface.
The error I get is in the title.... UDEV is set correctly
Apologies if I have missed something obvious!