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

[dgerman]

nrfjprog checks the target for 0xFFFFFF before attempting to write.

It should be successful not only if attempt to write the same value as is already present but also

if the value to be written is only  writing 0s where there are existing 1s.

For example  0x10001080  contains FFFFFF00 writing 00FFFF00 should succede 

Tank you.

[Amanda Hsieh]

Hi Dennis, 

nrfjprog checks the target for 0xFFFFFF before attempting to write.

 That's correct. 

-Amanda H.  

[Turbo J]

dgerman said:

For example  0x10001080  contains FFFFFF00 writing 00FFFF00 should succede 

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.

[dgerman]

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.

[Amanda Hsieh]

Hi Dennis,

dgerman said:

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

Yes, see this post.  

dgerman said:

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

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. 

dgerman said:

Is there a better way to change a single bit?

I believe this is the only way now. 

-Amanda H.

[dgerman]

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.