RE-programming the nRF52840 Dongle

RE: RE-programming the nRF52840 Dongle

RayFoulkes — Wed, 27 May 2020 13:28:13 GMT

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

[quote userid="69239" url="~/f/nordic-q-a/60930/re-programming-the-nrf52840-dongle/248002"]<ProgramSection alignment="4" keep="Yes" load="No" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" />[/quote]

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.

RE: RE-programming the nRF52840 Dongle

RayFoulkes — Mon, 04 May 2020 17:49:59 GMT

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!

Bye, Ray

RE: RE-programming the nRF52840 Dongle

haakonsh — Mon, 04 May 2020 14:09:47 GMT

Let me know if you need more assistance Ray :)

RE: RE-programming the nRF52840 Dongle

RayFoulkes — Mon, 04 May 2020 12:07:44 GMT

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

RE: RE-programming the nRF52840 Dongle

haakonsh — Mon, 04 May 2020 11:47:45 GMT

[quote user="RayFoulkes"]it sets it to all 1 not all 0[/quote]

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.

RE: RE-programming the nRF52840 Dongle

RayFoulkes — Mon, 04 May 2020 10:41:46 GMT

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.

RE: RE-programming the nRF52840 Dongle

haakonsh — Mon, 04 May 2020 09:37:37 GMT

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

[quote user=""]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.'[/quote]

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.

[quote user=""]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.[/quote]

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.