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.

[haakonsh]

The programmer app in nRF Connect for Desktop is not ideal for the dongle as you've noticed.
 

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.'

 This is correct, the DFU bootloader does not erase any memory outside of the image address space, this can cause issues if you're using flash to store application information. You should assume any data outside of an image's address space to be undefined after a DFU, given that the new image is smaller than a previous one.

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.

 Yes, this should work. You can write a script that pads the image with zeroes for the remainder of the address space. I'll ask the devs if this is something we can do for a future release of the Programmer app. 
Though this method is not really ideal for dual-bank DFU's as you limit the space available for the next DFU. 

[RayFoulkes]

Hi Haakonsh, OK thanks for the confirmation of my understanding. BUT, you now have me confused. I thought that when you "erase" the nvram it sets it to all 1 not all 0. You write about padding it with zeros - which, if I understand correctly, means that it cannot be written which would then be useless anyway for the program to write into.

In particular I am using gzll dynamic pairing which requires a 4k block to write the pairing info. I think I recall that it checks to see if the memory is all FFFF which means "unused". I think that I can deal with that for the 4k block I need. My application is not on the internet, just low security point to point comms, so there are no plans for in-field updating of the firmware.

I am also contemplating the use of command-line programming of the dongle, but I am currently struggling between nrfutil and nrfjprog - it all looks fairly complex.

[haakonsh]

RayFoulkes said:

it sets it to all 1 not all 0

 Yeah, you're correct, sorry, my bad. 

nRF Util is required for any DFU operation. If you have zero plans for any DFU's in the future you can just rip out the bootloader and DFU, and just flash the devices with a DK and a 6pin j-link needle connector from Tag-Connect, there should be a footprint for that connector on the bottom side of the dongle pcb.

[RayFoulkes]

Haakonsh, Thanks for the confirmation regarding 1/0. I did know about the Tag-Connect gold plated footprint but one of the reasons for using the dongle was the simple usb plug-it-in-and-program. The initial production run will be about 1000 dongles programmed by a not-so-skilful operator. That sort of number doesn't really justify setting up a jig for Tag-Connect (there are no retention holes for tag-connect as I recall). Also, using the DK is probably more complicated for the operator.

But, thanks for the direction to "only nRF Util" - I missed that in the doc. There will only be a couple of images to program so perhaps setting up nRF Util and scripting it will be OK.

I think that covers my original worries and gives me a great start on fixing the initialisation and looking at nRF Util a bit more closely. I will do "verify answer" on your latest comment if that is OK.

Thank you for your efforts, Ray

[haakonsh]

Let me know if you need more assistance Ray :) 

[RayFoulkes]

Hi again Haakonsh, that offer of further assistance is very nice, thank you, I really appreciate that. I won't bother you unless I am really stuck. This response is just FYI.

I realise that I could post-process the .hex file to add in a 4k chunk of all FF at the appropriate address, but that is a bit fragile for a production environment. First I am going to look at simply initialising the data area and telling the linker to emit instructions to write it. I think that I have seen in an example or gzp .h files a macro which starts of with 4 bytes, then another which calls it twice, then another calling that twice.... and so on. until there are 4K bytes, all FF. I just have to find it again! Then I will change the flash_placement file line (below) from "load=no" to load="yes" and hopefully see the 4K block initialised to all FF. Wish me luck!

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

Bye, Ray