The issue with the random mass erase of pyocd seems to still exist.
Therefore I installed “probe-rs”, but I failed to understand how to flash with that.
The help and their documentation seems to target some rust dev stuff, but is it possible to flash a already created hex?

I opened an issue - pyOCD, but to be frank, that is pretty much the situation I was afraid of. I spent already a lot of time in open source activities, I don’t want to extend that to pyocd.

14 days later

Unfortunately:

probe-rs download –chip nRF9160_xxAA –binary-format hex build_feather_nrf9151_ns/merged.hex –allow-erase-all
WARN probe_rs::vendor::nordicsemi::sequences::nrf: Core 0 is locked. Erase procedure will be started to unlock it.
WARN probe_rs::architecture::arm::core::armv8m: The core is in locked up status as a result of an unrecoverable exception
Erasing ✔ 100% [####################] 424.00 KiB @ 38.40 KiB/s (took 11s)
Programming ✔ 100% [####################] 424.00 KiB @ 38.78 KiB/s (took 11s) Finished in 21.98s

So the same issue as with pyocd.

(Maybe the log doesn’t show it, but it erases also the settings in flash.)

    AchimKraus this is because it resets and does not set the UICR App Protect registers correctly. I don’t suggest running the erase command for both since it is not the fast Nordic “wipe”/erase all.

    I’ll get you more info shortly.

      If you read these two registers, as far as I understand, they should be something other than 0×0. I set it to 0×50FA50FA during factory test.

      ❯ probe-rs read b32 0x00FF8000 1 --chip nRF9160_xxAA
50fa50fa
❯ probe-rs read b32 0x00FF802C 1 --chip nRF9160_xxAA
50fa50fa

      Here’s a quick and dirty recovery utility as doing a simple write will not work. It will also unlock the device if it’s truly locked.

      Windows
      Linux

      Simply run:

      recovery.exe
Got probe!
Unlocked device!

      It will look for the probe with VID/PID that matches the feather (it’s the same as the VID/PID for the RPi Debug Probe). Do a full chip erase and restore the UICR.

      Edit: added a note to the docs

        jaredwolff Do a full chip erase and restore the UICR.

        That “full chip erase” removes the settings from the flash. That’s the way to install the app, but to update, the intention is to keep the settings in flash.

        That’s intended for develop-devices. For prod-devices an update must be applied via FOTA, there the APP_PROTECT is also set and inhibit to flash a different app using the settings.

          With some more experience:

          It seems, that if a powered nRF9151 feather is connected to USB, the first time probes-rs executes results in:

          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

          After reset the feather with the button, it frequently works …

          What version do you have? Should be:

          ❯ probe-rs --version                                
probe-rs 0.27.0 (git commit: 7d59a31)

          Yep, that’s also my version:

          > probe-rs --version
probe-rs 0.27.0 (git commit: 7d59a31)

          Not sure, maybe this depends also on my switching the BUCK2 with USB.

          Hmm. I’m looking into it. I think probe-rs is doing some funny stuff. Stay tuned.

          7 days later

          @AchimKraus, I updated and put a PR with the newest CMSIS definitions for the nRF9151/61/20. You can download the latest with:

          cargo install --git https://github.com/probe-rs/probe-rs.git probe-rs-tools

          Seems fairly stable. Even in cases when the core was ‘locked’

          I would like to test it, but I’m not common with the tools around rust. I get

          cargo install --git https://github.com/probe-rs/probe-rs.git probe-rs-tools
    Updating git repository `https://github.com/probe-rs/probe-rs.git`
error: could not find `probe-rs-tools` in https://github.com/probe-rs/probe-rs.git with version `*`

          Hmm what version do you have? cargo --version

          You can also try this to see if your output matches mine:

          ❯ cargo install --git https://github.com/probe-rs/probe-rs.git               
    Updating git repository `https://github.com/probe-rs/probe-rs.git`
error: multiple packages with binaries found: binary_cargo_config, binary_cargo_config_toml, binary_project, gpio-hal-blinky, multiple_binary_project, probe-rs-tools, rtthost, smoke_tester, target-gen, workspace_bin, xtask. When installing a git repository, cargo will always search the entire repo for any Cargo.toml.
Please specify a package, e.g. `cargo install --git https://github.com/probe-rs/probe-rs.git binary_cargo_config`.

          Make sure you have the latest by running:

          rustup upgrade

          cargo install –git https://github.com/probe-rs/probe-rs.git
          Updating git repository https://github.com/probe-rs/probe-rs.git
          error: multiple packages with binaries found: binary_cargo_config, binary_cargo_config_toml, binary_project, gpio-hal-blinky, multiple_binary_project, workspace_bin. When installing a git repository, cargo will always search the entire repo for any Cargo.toml.
          Please specify a package, e.g. cargo install --git https://github.com/probe-rs/probe-rs.git binary_cargo_config.

          Terms and Conditions | Privacy Policy