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 Raymond, 

The protocol that nRF Connect uses to program the nRF528540 dongle is the DFU protocol. The nRF Connect automatically switch the dongle to bootloader mode and flash the board via the bootloader. The USB bootloader can be found here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble_sdk_app_open_bootloader.html?cp=7_1_4_4_2

The protocol is here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_dfu_transport.html?cp=7_1_3_5_2

The nRF Connect when given a hex file, will first convert it to a binary file. This is the place where your 4K of all 0xFFFFFFFF is realized. My assumption is that in the binary generated, there will be all 0xFFFFFFFF all the way from the end of your application until address 0x15FFF. 

NRF Connect will send all these 0xFFFFFFFF to the bootloader, and the bootloader will also write 0xFFFFFFFF into the chip, there will be no check.

The question is why it worked for the firmware with no 4K of blank at 0x15000 and it didn't work when there is that 4K. 

What we can do is to read out the hex dump from the dongle, and check the difference. 

From what you described that the device enter bootloader without going to the application, it may suggest that the CRC check was failed. 

If you can send us a sample hex files of a very simple application (blinking LED for example) one works and one doesn't we can try to figure out the issue. 

I assume your application already made with start address at 0x1000 ? (to avoid the MBR)

[RayFoulkes]

Hello again Hung Bui, OK, now I am baffled - I am unable to replicate the problem using Blinky. I used V16 SDK, recompiled blinky for the dongle, then edited the .hex file to include the zeroing of the memory from 15000. When I load it into nRFconnect programmer it shows two segments - one the original blinky and the section that I want reset. I load this into a clean dongle and it works just fine. I load my program over it and that only goes back to DFU.

I include some images (I hope). The first are blinky examples showing the result in the programmer:

The above shows the programmer after loading the file but before writing (for the second time) to the dongle. It shows the band of memory to be set to FFFFFFFF above the program.

The above is the same showing the size of the FFFFFFFF band. Just a note - there seems to be no relation with respect to scaling between the two windows. i.e. Bytes to height varies from window to window.

The above shows my application loaded into the programmer. When this is written and the dongle re-powered, it just goes into DFU mode immediately.

I will write a bit more in a subsequent response - I am a bit disappointed that I cannot replicate the problem in Blinky. Maybe I will try with a Gazell example next. (post - note OOPS I cannot do that because the gazell examples do not include the pca10059 nor do they support SES and that would be a big job for me to covert them).