Closed ceekdee closed 8 months ago
The RAK4631 (nRF52840/sx1262) is flashed through a set up using an nRF52840-DK with a SEGGER J-Link debugger/programmer. The wiring from the nRF52840-DK to the RAK4631 is taken from the following resource:
Perhaps this kludge is a bit much for probe-rs-cli?
the exact same firmware works with probe-run
and fails with probe-rs-cli
? that's very strange.
That wiring looks good. I wonder if it's some race condition, and probe-rs-cli/probe-run pop logs at different speeds so the different timing causes things to break?
I'd be helpful if you could get a standalone repro, I don't have any sx12XX board.
Unfortunately, I do not have any other type of sensor/communication board with an SPI interface to test if the SPI read error is ubiquitous for nRF52840 boards flashed through probe-rs-cli.
@Dirbaio - perhaps this issue can be closed when PR https://github.com/embassy-rs/embassy/pull/1595 is merged?
Now that I have a test environment available again, neither probe-rs nor probe-rs-cli successfully sets up the nrf52840 lora examples for SPI using TWISPI1. probe-run still sets up TWISPI1 successfully.
@Dirbaio I think we can close this as: a) LoRa examples were moved to lora-rs organization b) probe-run has been deprecated.
For nrf52840 LoRa examples (using Spim TWISPI1), the probe-run method still results in correct SPI operation. For example:
However, the probe-rs-cli method results in SPIM read failures (the first 2 read operations return all 0xff values, the second read operation resulting in a panic since the read 0xff value is an invalid index value):
All the nrf52840 lora examples will fail using probe-rs-cli. The stm32wl, stm32l0, and rp LoRa examples successfully run with probe-rs-cli.
probe-rs-cli --version
Temporary workaround: