You probably installed with apt. I did have a link to the preferred way to install but it was in a tiny section that was probably overlooked.
https://www.rust-lang.org/tools/install
I would uninstall the one installed using apt and install using rustup.
I will try that later today.
probe-rs --version
probe-rs 0.27.0 (git commit: 9fb82c01)
achim@ry7$ ./flash-dev.sh feather51
v2.9.1 (sysbuild)
feather51
+ probe-rs download --chip nRF9160_xxAA --binary-format hex build_feather_nrf9151_ns/merged.hex
WARN probe_rs::vendor::nordicsemi::sequences::nrf: Core 0 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
+ probe-rs reset --chip nRF9160_xxAA
WARN probe_rs::vendor::nordicsemi::sequences::nrf: Core 0 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_allPressing the “reset button” short before flashing works ;-).
Maybe it’s caused be disable/enable the RP2040 with USB.
@AchimKraus can you change the target to nRF9151_xxAA?
./flash-dev.sh feather51
v2.9.1 (sysbuild)
feather51
+ probe-rs download --chip nRF9151_xxAA --binary-format hex build_feather_nrf9151_ns/merged.hex
Error: Connecting to the chip was unsuccessful.
Caused by:
0: An ARM specific error occurred.
1: Error using access port FullyQualifiedApAddress { dp: Default, ap: V1(0) }.
2: Failed to read register DRW at address 0xd0c
3: An error occurred in the communication with an access port or debug port.
4: Target device responded with a FAULT response to the request.
+ probe-rs reset --chip nRF9151_xxAA
Error: Connecting to the chip was unsuccessful.
Caused by:
0: An ARM specific error occurred.
1: Error using access port FullyQualifiedApAddress { dp: Default, ap: V1(0) }.
2: Failed to read register DRW at address 0xd0c
3: An error occurred in the communication with an access port or debug port.
4: Target device responded with a FAULT response to the request.Procedure:
until I reset.
I’m newer to Zephyr, but I’ve climbed to the point where the 9151 is working with our custom carrier board and is generally functional.
I see the the same behaviour AchimKruas lists above while running Windows 11, cargo version 1.86.0, and probe-rs installed using cargo install from the repo in this thread. I have been using the 9160 target and SDK 2.7.0.
I use the recovery tool instead of hitting reset, but otherwise the list is the nearly same. The first flash fails on power up. The recovery util brings the board back, but it takes 2 attempts immediately after using recovery. Past that point most flash attempts succeed so long as the NRF9151 remains powered on either by USB or our carrier board.
What —chip argument are you using? It should be nRF9151_xxAA
AchimKraus I suggest keeping buck2 enabled during development since it’s critical for the CMSIS DAP to work. Or…
One thing I’ve done in some recent firmware is turn buck2 on immediately on boot every time. Then after a few seconds manage the buck however necessary. It guarantees that you have enough time to establish a connection.
Hope that makes sense!
jaredwolff
nRF9160_xxAA
Using nRF9151_xxAA gives this error
“Error: The chip ‘nRF9151_xxAA’ was not found in the database.”
I’ll try pulling installing with "cargo install –git https://github.com/probe-rs/probe-rs.git probe-rs-tools –rev e5898b6
" as I believe I left off the –rev & commit number.
Reinstall clears that up for me, switched to nRF9151_xxAA and now flashing on first boot works!
Reinstalled using: cargo install –git https://github.com/probe-rs/probe-rs.git probe-rs-tools –rev e5898b6
Original install a couple days ago was: cargo install –git https://github.com/probe-rs/probe-rs.git probe-rs-tools
As I wrote, as long as I reset the feather after plugin USB, it works (at least the couple of times I’ve tested it).
Therefore I guess, that’s the approach for me … until I run into the issue again even after reset ;-).
Thanks all. Sorry for the bumps in the road here. I will definitely want to test your use case more @AchimKraus since USB auto-detect is on my list. 
If I find anything else useful, I’ll get back to you guys on this thread.
Sorry for the bumps in the road here.
Better struggling on new roads than stick in circles on old ones ;-).
since USB auto-detect is on my list
Yesterday I build the first prebuild images of my client for ncs 2.9.1, see coaps-client - prebuild. Maybe that’s a short-cut.
If you prefer to add USB detection to your app, you may have a look at
and
@AchimKraus I did finally play around with dynamic BUCK2 control and can confirm after restoring power the RP2040, which re-initializing the serial port, the SWD interface doesn’t come back until you hit the reset button (resetting the 9151).
Beside of the function to flash the device, the other stuff as logging and energy saving works well.