Required hardware setup

[sense-Jo]

Hello @hdoordt,
thank you for publishing this project.
I would like to try it out, since I'm currently working on something similar. However, I failed to get running.
I installed powertest by running cargo install --path /path/to/powertest, and then ran cargo test --test power, just as you described it in the readme.
However, it fails with Error: No probe found for chip nrf52840.
Of course, I have the PPK-II and a programmer connected to an nrf52840 module.
The programmer is the onboard-JLink of an nRF51-DK. Should that be a compatible setup?
I verified the probe is detected by installing cargo-flash:

> cargo flash --list-probes
The following debug probes were found:
[0]: J-Link (J-Link) (VID: 1366, PID: 1015, Serial: 0006815XXXXX, JLink)

Sadly, I don't know much about Rust and it's ecosystem, thus I have a hard time figuring out what your code does regarding the probe detection.

[hdoordt]

Hi @sense-Jo. You mention that you're using an nRF51-DK. The example firmware project is specific for the nRF52840-DK, and needs to be edited for it to work on an nRF51. To that end, you'll first have to edit fw-example/.cargo/config.toml, replacing the chip option on line 2 to your chip.

Furthermore, you'll need to use nrf51-hal instead of nrf52840-hal. You can edit fw-example/Cargo.toml to use nrf51-hal (version 0.15.1 should work, I believe).
Once that's done, you can update fw-example/src/lib.rs line 7, to import nrf51-hal instead of nrf52840-hal.

I haven't tried or compiled this, so please let me know if it works.

[sense-Jo]

Thank you for your response.
Just in case this was not clear, I was using the nRF51-DK only as a programmer for a nRF52840 module.
Today, I could get things running by using a separate J-Link along with the nRF52840 module. So I guess that probe.rs does not detect the nRF52840 correctly if it's connected to the Debug_out of the nRF51-DK (even though flashing with nrfjprog works fine that way).

Unfortunately, switching to nRF51 the way you described did not work. I get the following output:

> RUST_BACKTRACE=1 cargo test --test power
   Compiling nrf51-pac v0.11.0
   Compiling nrf51-hal v0.15.1
   Compiling panic-probe v0.3.0
   Compiling defmt-rtt v0.3.2
error: failed to run custom build command for `nrf51-hal v0.15.1`

Caused by:
  process didn't exit successfully: `/home/user/opt/powertest/fw-example/target/debug/build/nrf51-hal-73b368cb29c48ba8/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'nrf51-hal only supports thumbv6 targets (attempting to build for `thumbv7em-none-eabihf`)', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/nrf51-hal-0.15.1/build.rs:9:9
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
     2: build_script_build::main
               at ./build.rs:9:9
     3: core::ops::function::FnOnce::call_once
               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/ops/function.rs:248:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

However, since I have a working setup now, we don't have to investigate this further. But in case you still want to so, I'm willing to help testing.

[sense-Jo]

Ah, by the way, I occurred a compile-error after switching back to nRF52 from nRF51, and doing a system update (not sure what the actual cause was):

error: linking with `flip-link` failed: exit status: 1
  |
  = note: "flip-link" "-flavor" "gnu" "/tmp/rustcsYnn0H/symbols.o" [...]
  = note: [...]
          rust-lld: error: undefined symbol: _critical_section_1_0_acquire
          >>> referenced by lib.rs:29 (/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/critical-section-0.2.8/src/lib.rs:29)
          >>>               defmt_rtt-bdd3219962ef4dd9.defmt_rtt.4021abc7-cgu.0.rcgu.o:(_$LT$defmt_rtt..Logger$u20$as$u20$defmt..traits..Logger$GT$::acquire::he0d39be7dfb50db4) in archive /home/user/opt/powertest.new/fw-example/target/thumbv7em-none-eabihf/debug/deps/libdefmt_rtt-bdd3219962ef4dd9.rlib

          rust-lld: error: undefined symbol: _critical_section_1_0_release
          >>> referenced by lib.rs:45 (/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/critical-section-0.2.8/src/lib.rs:45)
          >>>               defmt_rtt-bdd3219962ef4dd9.defmt_rtt.4021abc7-cgu.0.rcgu.o:(_$LT$defmt_rtt..Logger$u20$as$u20$defmt..traits..Logger$GT$::release::h53ef9e6b20e293de) in archive /home/user/opt/powertest.new/fw-example/target/thumbv7em-none-eabihf/debug/deps/libdefmt_rtt-bdd3219962ef4dd9.rlib

          flip-link: the native linker failed to link the program normally; please check your project configuration and linker scripts

I could solve it with these changes to fw-examples Cargo.toml:

  [dependencies]
- cortex-m = "0.7.3"
+ cortex-m = { version = "0.7.3", features = ["critical-section-single-core"] }

[hdoordt]

Hi @sense-Jo,

There have been some developments around the cortex-m crate that caused this error. If you like, please open a PR with the suggested fix