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??) "

[RayFoulkes]

OOPs, I have just realised that there is a problem with the strategy of writing FFFFFFFF to every 32 bit word in the memory allocated to the Gazell database. If nRFconnect programmer is stupid enough to actually write FFFFFFFF (as opposed to recognising that, on an erased page, it will have no effect), then that will consume one "32 bit write" of the number permitted before the next erase. On the nRF52840 that number of permitted writes is only 2 - half the writes already gone as a result of my attempt at initialisation. Can anyone confirm whether nRFconnect programmer does actually write 32 bit words that are all FFFFFFFF or just leaves them erased?

It would be REALLY nice if someone could document what the nRFconnect programmer actually does - or have I said that before?

[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]

Hi Hung Bui,  I will respond to your answer in detail tomorrow. I hope that I can make a .hex file of the blinky example with the "zero memory" built in. If I can I will post that as well.

I will also study the DFU protocol which looks interesting.

Thanks for your attention.

Regards, Ray

[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).

[RayFoulkes]

You wrote

Hung Bui said:

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

I do not know  how to read the memory of a Dongle. When used in DFU mode, the menu items for reading and saving the contents of the memory of the dongle are always greyed out. The only buttons ever enabled are "reset" and "write". I have confirmed with Nordic that that is always the case. You cannot do anything but write to the dongle using the programmer.

I do have two hardware sdk so I do know that, if I added a socket to the dongle and had the appropriate lead, I maybe could use the Jlink buried in the sdk to read the memory but I don't have the components at the moment to do that.

Hung Bui said:

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

Yes, you will see that from the screen captures that I posted. Also, please remember, without the zeroing the memory, the application works fine as does the DFU after I press the reset button to trigger it. (my application does not know about DFU). I have checked very carefully, there is no difference in the .hex files in the part which contain the program between the ones that FFFFFFFF the memory and the ones that do not.

Hung Bui said:

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. 

Exactly so. Why does blinky work, and not my application?

Hung Bui said:

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.

That would be fine with me.

I am wondering whether to give up on trying to reset the memory at program load time using the programmer. It will only be of importance in the case where the dongles are being re-purposed i.e. writing a new program and changing from Gazell device to host or vice versa. I might be able to write a program to detect the change of role and zero the memory myself during initialisation.

Thank you for the references for the DFU - I had a quick look, but studying that will take more than a few minutes on a Tuesday morning!

Thank you for your attention,

Regards, Ray