Open ninjasource opened 1 year ago
I have tested the suggested fix above on an nrf5340-dk but, unfortunately, I do not have an nrf52840-dk rev 3 to test with. This is related to: #368
Hi @ninjasource, thank you for your report.
Two observations:
For me running a simple hello world program on the nrf52840-dk takes 1.179s without --erase-all
and 1.494s with --erase-all
. So I can't observe the big difference you are experiencing.
Secondly, I don't think that the probe-rs-cli
command you are using is actually triggering an erase_all
. There is the --allow-erase-all
(which you are setting) and the --chip-erase
(which you are not setting).
Can you please try running probe-rs-cli
with --chip-erase
and report what happens?
As far as I understand the "erasing sectors" in the probe-rs-cli
output does not refer to the erase_all
. If you run probe-run
without --erase-all
but with -vv
(double verbose) you can atill observe (HOST) DEBUG Erased sector of size 4096 bytes in 180 ms
two times which adds up to the 8.00 KiB
reported by probe-rs-cli
.
My sincere apologies for the late reply, I have been away.
@Urhengulas, I ran the chip erase function. Oddly enough the nrf5340 still needs that --allow-erase-all
flag to unlock the chip on power up even though it is erasing the chip anyway.
This completes successfully on the nrf52840 in about half a second so this confirms your observation (in point 1):
probe-rs-cli erase --chip nRF52840_xxAA --allow-erase-all
To answer point 2, this completes on the nrf5340 after 34 seconds although on most runs it simply times out:
probe-rs-cli erase --chip nRF5340_xxAA --allow-erase-all
So I guess the issue is with the probe-rs chip erase
command because nordic's programmer app takes about 5 seconds to do a full chip erase (and then some). I have come to realize that the --erase-all
and --allow-erase-all
commands are completely different things, the latter command being responsible for unlocking the chip.
I also ran probe-run with the -vv
flag and the nrf52840 generated a 7MB log whereas the nrf5340 generates a 38MB file. Too big to pollute this thread with though and github does not allow zip files to be attached to issues. I couldn't spot anything obvious other than the fact that the nrf5340 was doing a hell of a lot of register reading and writing for something that is supposed to be erasing a chip. Let me know if you'd like me to attach the log file to this thread.
Can you verify which version of the nRF52 you have? Apparently some later revisions changed how flash erasing works.
I also ran probe-run with the
-vv
flag and the nrf52840 generated a 7MB log whereas the nrf5340 generates a 38MB file. Too big to pollute this thread with though and github does not allow zip files to be attached to issues.
I think you can attach files by either drag-and-drop or by clicking on the bottom edge of the text input field. And I just tried and was able to upload a zip file.
So I guess the issue is with the probe-rs chip
erase
command because nordic's programmer app takes about 5 seconds to do a full chip erase (and then some). I have come to realize that the--erase-all
and--allow-erase-all
commands are completely different things, the latter command being responsible for unlocking the chip.
Can you please report the issue to probe-rs
and reference this issue there?
Describe the bug Hi, I am using the latest version of probe-run (built from git) to flash my nrf5340-dk. When using
probe-run --chip nRF5340_xxAA --erase-all
for a cargo runner the process erases the entire flash area every time which takes about 35 seconds. It does this regardless or weather or not it needs to. I believe that the nrf5340 requires an erasure of certain flash areas after power on or hard reset to unlock the device before a debugger like probe-run can work with it. If you don't do this you get the following error message from probe-run:An operation could not be performed because it lacked the permission to do so: erase_all
The
probe-rs-cli
tool has a flag calledallow-erase-all
which will only erase appropriate flash areas if required. That means that erasing the entire chip is not required once it has already been powered up and unlocked (power cycle or hard reset ends this). Additionally, I noticed thatprobe-rs-cli
only requires an additional 10ms to flash the device upon power up so I don't believe that it erases the entire chip, or if it does, it is many times faster than probe-run at doing it.Looking at the code, I see that when the
--erase-all
flag is passed toprobe-run
the-allow-erase-all
permission is set when interacting withprobe-rs
. Redundantly, I believe, theprobe-run
tool is also performing a full erasure of the chip before flashing.To Reproduce Steps to reproduce the behavior: TLDR: Use the following runner in cargo config:
probe-run --chip nRF5340_xxAA --erase-all
.cargo/config.toml
rustflags = [ "-C", "link-arg=-Tlink.x", "-C", "link-arg=-Tdefmt.x", ]
[build] target = "thumbv8m.main-none-eabihf" # = ARM Cortex-M33
[env] DEFMT_LOG = "info"
Write
memory.x
Write
Cargo.toml
[dependencies] cortex-m = { version = "0.7.6", features = ["critical-section-single-core"] } cortex-m-rt = "0.6.10" defmt-rtt = "0.4" panic-probe = { version = "0.3", features = ["print-defmt"] } defmt = "0.3"
[profile.release] debug = true
The main issue if there is a 35 second delay between this line:
and this line
When powering up the device for the first time and using the probe-rs-cli tool I get the following output:
As can be seen, it runs in under a second.
Suggested fix I would like to suggest that we remove the following code in the flash function of
main.rs:164
since probe-rs already handles this:I would also like to suggest that the flag be renamed to
allow-erase-all
which I think is more appropriate. Please let me know and I can create a PR but this is such a tiny fix that one of the maintainers might want to just throw it in quickly.David