nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user54487 — Thu, 12 May 2022 12:21:41 GMT

Has there been any change in ideas on nrfjprog's requirement that destination must be FFFFFFFF ?

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user18935 — Fri, 15 Jan 2021 23:03:49 GMT

Violating nWrite won't get you an invalid value immidiately. You would get a weak cell that could change its value inside the (otherwise guaranteed) time period in the PS.

You don't want your flash data changing in, for example, one or two years instead of 20.

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user54487 — Fri, 15 Jan 2021 22:36:20 GMT

Thank you for your response and the link to the previous discussion which states that "flash endurance is given only in erase cycles"

It also states that "You can write again to the same location, but only to change more ones to zeros"

This is limited to the nWrite specification which for the NRF52382 is 181 (for a particular 512 byte block,) and for the NRF52840 and NRF52811 is 2 (for a particular word) before an erase must be done.

Perhaps you could create an enhancement issue for nrfjprog to check if the current contents of the word has any 0 bits that --memwr is attempting to change (back to) a 1 and permit the write if there are none.
A better approach would be to issue the write, verify it and only fail if the verify fails which would only be successful no 0s were attempted to be changed and nWrite has not been violated.

Either of these are a much better approach than forcing an erasure of the entire page.

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user77782 — Fri, 15 Jan 2021 14:05:24 GMT

Hi Dennis,

[quote user="dgerman0"]Are flash erasures more "wear" intense than simply zeroing several bits?[/quote]

Yes, see this post.

[quote user="dgerman0"]Would successful --verify in combination with memwr insure correct writing?[/quote]

The provided image_file contents are compared with the contents in the device code flash, RAM, UICR and XIP regions for devices equipped with a QSPI peripheral connected
to an external memory device, and fail if there is a mismatch.

[quote user="dgerman0"]Is there a better way to change a single bit?[/quote]

I believe this is the only way now.

-Amanda H.

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user54487 — Tue, 05 Jan 2021 23:51:33 GMT

Thank you for your prompt reply.

Are flash erasures more "wear" intense than simply zeroing several bits?

Would successful --verify in combination with memwr insure correct writing?

In many cases only some of the words in UICR need to be changed.

It seems that what is required to modify a single bit is to:

1) --readuicr UICR.HEX
2) --eraseuicr
3) Edit UICR.HEX and extract to 16 byte line containing the address of the data to be changed
4) create 4 --memwr --verify commands from the line extracted from UICR.HEX revising the desire word
5) run the 4 --memwr -- verify commands

Is there a better way to change a single bit?

Seeger J-LINK permits this type of operation.

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user18935 — Mon, 04 Jan 2021 15:06:59 GMT

[quote userid="54487" url="~/f/nordic-q-a/70043/nrfjprog---memwr-0x10001080---val-0x01010101-shouldn-t-fail-second-time"]For example 0x10001080 contains FFFFFF00 writing 00FFFF00 should succede [/quote]

Touble is the limited amount of allowed flash overwrites.

For example: NRF52840 PS (1.1) chapter 4.3.10.1: nWrite maximum is 2 (two). Your changes could allow more overwrites than that, violating flash specs. The way nrfjprog implements writes is safer.

RE: nrfjprog --memwr 0x10001080 --val 0x01010101 shouldn't fail second time

user77782 — Mon, 04 Jan 2021 14:09:46 GMT

Hi Dennis,

[quote user=""]nrfjprog checks the target for 0xFFFFFF before attempting to write.[/quote]

That's correct.

-Amanda H.