Erasing gazell pairing memory.

[RayFoulkes]

Environment - windows 10, ses release 4.12 nRFconnect programmer 3.3.3 using gnu C nRF52840 dongle programming with DFU. No softdevice, Gazell only.

I have two hex files, one containing my nrf52840 dongle program and the other containing the program plus a section erasing 4k of memory from 15000
With the same difference between .hex files (but obviously not identical .hex files) using ses and Jlink on the PCA10056 dev kits, both .hex work just fine.

If I use nRFConnect v3.3.3 programmer to load the one containing just the program onto a dongle, all runs just fine.
If I use nRFConnect programmer to load the one which also erases the 4k of memory, the program does not run at all, when powering up the dongle it goes into bootloader mode without pressing the reset button.
.
They are built using ses. The only difference in the build is in the file "flash_placement.xml".
The only difference in that file is in the line:
<ProgramSection alignment="4" keep="Yes" load="No" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" />
which is changed to:
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" />

There is not a single character of difference in either the .map file or the section of the .hex file which contains the program.

The only difference in the hex file is a section which looks like:

:020000021000EC
:10500000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10501000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10502000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10503000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10504000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70

               *
               *
               *
:105FA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01
:105FB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1
:105FC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE1
:105FD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD1
:105FE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC1
:105FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB1

(I missed out a lot of them because they are boring).
The first line sets the start address and the subsequent lines fill them with FF.

Just to prove a point, if I edit out the above lines erasing the memory from the hex file and then use nrfconnect programmer to write the resulting .hex the program runs just fine.
If I write the program containing the erase, and then re-write it with the one without the erase, then it works just fine AND it looks like the erase actually worked i.e. I have to re-pair the client with the server dongle.

I then tried to edit out the application and keep JUST the erase commands - Ah, nRF connect knows better than me because it then asked me what soft device I wanted (that being none which wasn't allowed) and refuse to program the dongle unless I gave an answer.

Can anyone throw a light on just how to use nRFconnect programmer to set some memory to FFs in the region 15000 for 4K and actually have a working dongle.

If a Nordic employee is interested, I can send you the .hex files.

Regards, Ray Foulkes

PS - I do have some options still:
a) (assuming that nrfutil does not have the same limitations) switch to command line programming using some Bash scripting.
b) tell the end user to load the non-working program, then the working program and the pairing memory will have been erased - very amateurish but it works.
c) do what I have done for the device end - make it possible to erase 4K of memory when starting the dongle with finger on the button instead of just the device pairing record.
d) persuade Nordic to make a gui program that just does what it is told, and doesn't try to be over clever (or try to make one myself)

PPS, It would be REALLY, REALLY nice if someone could document the actual logic used by nRFconnect programmer in the user guide. It pretends to be able to load whatever you give it (it does not say otherwised) but it is blatantly not true, well, it might load it, but it somehow prevents it from running. I have spent a week trying to understand what was happening.

In order to save me much frustration and time, can someone answer the question "If I try to use the command line nrfutil will I simply hit the same obstacle (i.e. does nrfConnect programmer simply pass on the defects of nrfutil??) "

[Hung Bui]

Hi Ray,

You can read the hex dump by connecting a programmer (nRF52 DK) to the dongle. This requires you to solder the header on port P1. and then use a 10 pin cable to connect the debug out port on the DK to this header. This way you can access the dongle flash directly without using the bootloader (you can program the dongle ). Then you can read the code out either using nrf connect or use "nrfjprog.exe --readcode" command line tool. 

But I think I found what could be wrong here. It's the CRC check failed. Most likely because your code will write to the 4K "blank area" to store gazell data. And because of that CRC will fail. The bootloader expecting your application as a whole from 0x1000 to 0x15FFF. And any modification to flash in this range will result in CRC check fail on booting. And the bootloader will enter DFU mode. 

When you don't include the "blank area" the bootloader wont check the address from 0x1000 to 0x15FFF but only to the last address of your code, meaning writing to 0x15000 won't affect CRC. 

So I think the easiest solution is still to use 2 binaries, one to erase flash, and one to start normal application. Or you can include a feature in the code to erase that 4kB of data when you press a button or when you send a command. For example, when application detect you hold SW1 when plug the dongle in USB port, it erases the 4kB flash. 

[RayFoulkes]

Hi Hung Bui. Thanks very much for the explanation. I did not understand the consequences of the bootloader considering my data area as part of the program. I imagined that the start address of my program was simply hard-wired into the hardware for start-up once I had written the NVRAM with my program. I did not realise that, after programming with the DFU bootloader, the bootloader still intercepted the start-up sequence and carried out checks. I thought to make that happen I had to add bootloader functions to my program. Now all is clear - once the bootloader is loaded onto a processor it ALWAYS runs first, even if it doesn't enable the USB port if it finds a valid program loaded.

I did know about the use of the DK to both load and examine memory but unfortunately I am stuck a very long way from my electronic workshop containing all my sockets, cables etc. The only thing I brought with me was some dongles and the DKs. I could start ordering parts but there is no point if the bootloader is guaranteed to fail the crc check after Gazell writes into the NVRAM.

Hung Bui said:

So I think the easiest solution is still to use 2 binaries, one to erase flash, and one to start normal application.

That was my chosen work-around.

Hung Bui said:

Or you can include a feature in the code to erase that 4kB of data when you press a button or when you send a command.

I already use the white button on the device end to permit re-pairing but that is used in the field, not during device preparation.

The reason I was trying to do this in one step is not for me or some other techie but because there may well be a thousand or two of these being programmed (and potentially re-programmed and re-purposed) by people who are not that technologically inclined. Every step I add, including holding finger on button when powering up, just adds another operation to go wrong.

I have already labelled one .hex as "erase.hex" so for re-purposing, they will just have to load that first. Unfortunately the volumes are not sufficient to warrant setting up an auto-programming system.

Thank you once again for your efforts - I really appreciate the help of the community - this software and hardware environment is not the simplest to understand.