A clue for Programmer validation

[Gabriele]

Hi all,

we use nRF Connect for Desktop Programmer tool for flashing nRF5340 at production plant.
Our Regulatory Affairs & Quality Assurance dept. is asking for a validation of this tool.
In essence I have to provide an evidence the program written to internal Flash is exactly the HEX file I've sent to it.
Maybe the tool already performs such a check internally.
Is there anybody out there knowing the tool enough to identify an existing evidence - or a simple way to devise one ?

Thank you

[Einar Thorsrud]

Hi,

nRF Connect for Desktop Programmer is not intended to be used for production programming and does not support verifying programming at the moment. At the moment you need to use another tool for verifying, for instance nrfjprog. With that you can verify programming using the --verify option, which can also be combined with --program to do both in a single operation.

[Gabriele]

I think the shortest path is trying to validate internally the Programmer tool.
The validation should follow through these steps

1) click "Add Hex file" (merged.hex, the program to be flashed)
2) click "Erase & Write"
3) click "Read"
4) click "Save as file" (nRF_Connect_Programmer_1629380411895.hex, the read-back file)
5) compare files, ensuring merged.hex content is included in nRF_Connect_Programmer_1629380411895.hex

It works.
What remains unclear is the meaning of an additional tail in the read-back file.
Can you help to figure out its origin ?

[Einar Thorsrud]

Gabriele said:

It works.

This works to read out the flash, but not to validate that the flash was correctly programmed. In the mean time here the device is reset and if the application writes to flash you will see a difference. With a proper tool it will only compare the flash on the device with the flash region in the .hex file you are comparing with.

Gabriele said:

Can you help to figure out its origin ?

What device is this (to know the flash size) and what does the firmware you program include and do? What is the memory map, does it write to flash using FDS or something else?

Out of curiosity: why do you want to use nRF Connect Programmer for production programming instead of a more suitable tool?

[Gabriele]

This makes perfect sense. When the application get started there are LittleFS initialization and UICR writings.
Why I don't use nrfjprog ? At production plant they prefer to work with Windows PC.
Using nrfjprog on Linux works fine (verified with ver 10.12.1).
Using nrfjprog on Windows 10 leads to crashes (verified with ver 10.13.0).

[Einar Thorsrud]

I see. nrfjprog works on windows as well, but it seems there may be an issue there that requires investigation. (There are also other Windows tools that would do this, for instance SEGGER J-Flash).

[Gabriele]

I've found out the problem.
I mistakenly installed the Command Line Tools Win32 version instead of Win64. Now I could rely the verify command of nrfjprog.

Anyway, could be I'm wrong, but I still think production guys prefer to click buttons of a GUI than typing strings on a command shell.

Thank you for valuable help.