RE-programming the nRF52840 Dongle

[RayFoulkes]

I would like clarification on the use of the nrfConnect programmer for RE-programming the "dongle" a.k.a PCA10059. NOTE: NOT "programming a virgin dongle"

Reference: The user guide "nRF Connect Programmer" version 1.4.2 user guide version 1.2 updated in April of this year, executing in the framework of nRF Connect Version 3.3.3 (and earlier ones) on both Linux (ubuntu 18) and Windows 10 fully patched.

There is an implication in infocenter.nordicsemi.com/index.jsp
that a non-virgin dongle can be re-programmed because it reads "this step is not needed if the currently running application uses the DFU trigger library" i.e. the dongle is not virgin.

However the User Guide clearly says "Erase & write clears the written memory and programs the files added to the File Memory Layout".
Therefore logically the menu entry "write"  DOESN'T clear the memory to be written before it programs the files added to the File Memory Layout.

The user guide is silent on the topic.

It is my understanding of nvram that the writing process can only convert binary ones to zeros and not vice-versa so unless the area written is
already all ones, then the writing will go ahead but will simply be a logical NOR to the binary already present  ones to zero, original zeros remain. i.e. a corrupted write.

I have been unable to find any means of getting the "Erase and Write" menu enabled when attempting to write a dongle using the dfu bootloader via USB.
In fact the only two buttons on the "nRF Connect Programmer" that ever seem to be enabled when using USB are "reset" and "write" so we cannot even write out to a file the content of the nvram on the dongle to validate the writing ourselves.

We will be using dongles for a pre-production run with several different .hex variants so there will be a large number programmed. Before doing that I would like the following confirmed or an alternative wording suggested:

1. The user Guide should really read 'When programming the Dongle in dfu mode using USB, the only two buttons that will ever be enabled are "reset" and "write".
When "write" is used, any 4k block of nvram that will potentially be written is first erased, the block is written, read back and verified against the file to be written'. i.e. only memory in the range of the .hex will be erased.
Also, for the dongle, there is no method available to you on "nRF Connect Programmer" to output the content of the nvram to a file on the computer.'

2. Now, if that is actually true, there is an implication that memory outside that to be written as a result of writing the hex file, may well have been written for a previous program
so that, if it is programmatically written from the application, the only way that it can be guaranteed to be all 1s is to initialise it in the HEX file to all ones there being no way to erase this in nrfConnect.

(But I am only guessing so I would like confirmation of what is actually true)

I spent some time searching the devzone for clarification. For example: Contained in answer 43636 is "The erase button in nRF Connect Programmer will always keep UICR,
MBR and the Bootloader, and is whited out when there is nothing else to erase."

But since "erase and write" and "erase" seem to be always "whited out" this would seem not to be true, or perhaps only apply when USB/dfu is not in use.

Another question, more or less identical to mine, https://devzone.nordicsemi.com/f/nordic-q-a/55761/nrf-connect-programmer-erase-button-always-disabled implied that answer 43636 is simply untrue and that was the reason why "erase" and "erase and write" are whited or else the dfu bootloader would be erased.
However, the answer to the question above simply gave references back to the "programming a virgin dongle" instructions. The implication of the answer is that, once programmed, a dongle would need to use a DK for re-programming, which, I admit, would be very inconvenient.
I tried commenting on that question a couple of weeks ago but received no feedback - it is rather old though.

I am contemplating abandoning nRF connect in favour of command line - at least the explanation is more extensive and I think I will be able to script it in bash.

Meanwhile I would really appreciate a definitive explanation of the behaviour of the nRF Connect Programmer. Even better, an updated user guide telling the users what it actually does instead of simply repeating the content of the labels on the buttons.

[RayFoulkes]

For Posterity: The last comment I made was that I would change the load="no" to load="yes" of the line:

RayFoulkes said:

<ProgramSection alignment="4" keep="Yes" load="No" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" />

That caused a 4Kbyte section of FF to be loaded, starting at address 15000 in addition to the normal application. True, it did, but then the application would not boot - the dongle simply went back to the DFU without pushing the reset button. The reason is that the DFU (I think is the DFU) takes not only your program code but all memory from the lowest address to the highest address as your "program". It then calculates the CRC of that and remembers it. If, on subsequent power-ups, the CRC of the memory is different to that calculated at load, it refuses to boot. Since GZP_PARAMS is a data store, not a program, it is more or less guaranteed to change. Ipso facto your program will never run.

The simplest work-around is to program the dongle TWICE, once with your program + memory zero (it does actually zero it) then once without the memory zero so the data area is not included in the CRC the second time around.

There is a BUT, and that is I am told that the DFU does no optimisation i.e. it clears an address range to all FFFFFFFs and then writes in what it is told (which for clearing is FFFFFFFs and therefore pointless). Sounds innocent, but I have not established yet whether such writing consumes one of the "maximum number of writes between erasings" of the chip. To be investigated.

So, it would appear that the nRFconnect programmer is likely to be dangerous to use for re-purposing (i.e. changing the program on a dongle) if the subsequent program reserves ANY NVRAM for data without a method of the user zeroing the data programatically since the programmer (and possibly the DFU itself) will not erase any memory outside the program area.

My final alternative is to write a tiny program which does one job only, that is to erase the relevant data area programatically instead of at load time. Load and run this once, THEN load the real application without attempting to zero the memory. I may report on this subsequently.