This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is nrf at all production friendly?

Hi

I am using the nrfjprog.dll to program my UUT (nrf51822) during our production PCBA test. Apparently this is a bad idea to use this dll since you sometimes change the definitions and then production stops if we update nrf tools. The reason that I have to update is that we start to use the nrf51802 instead of nrf51822 and then I had to update nrfjprog.dll. And then everything stops working because you Guys have added the text "NRFJPROG" in all function names. Should I use the command line Tool (nrfjprog.exe) instead or do you also change in that every now and then without making it backwards compatible? image description

  • Sorry for the inconvenience, but the name change was needed. When we compiled for OSX there was a conflict in several function names (read and write for example). There were in some very common library functions in OSX that were called the same and had the same number and type of parameters in the same order.

    We try not to break the compatibility of our tools, because we understand that every change is an inconvenience. If the API is changed, we update the major revision number. If you look at the changelog in nrfjprog_release_notes.txt you can see that it was changed to 5.x.x to 7.x.x due to the addition of the nRF52 that required some changes, and from 7.x.x to 8.x.x due to the change you mentioned.

    Regarding nrfjprog.exe, we also change when needed, but we try to avoid it as much as possible. You can still use the dll, and there are no plans to modify the API in the future.

  • An alternative solution is to use the IDAP-Link to parallel program multiple board at once. Supports both nRF51 & nRF52 series. No mergehex require to flash all 3 hex files.

  • Hi

    Thank you for your reply. Ok, that looks really nice. Especially the parallel programming. That is very good for production. Unfortunately we cannot do that with nrfjprog.dll so I can imagine that the IDAPnRFProg.exe does not use the nrfjprog.dll?

    However when I look at the IDAPnRFProg.exe usage description I miss some functions to read and write bytes and erase sectors (just like --memrd, --memwr and --earsepage in nrfjprog.exe)

  • The IDAPnRFProg does not use nrfprog.dll. It does not have the read/write. What would be the requirements for those ? The IDAPnRFProg can flash all 3 hex (softdevice + app + DFU) without requiring to mergehex. It updates the UICR automatically so you don't need memwr to manually update it.

  • We use read function to read out certain addresses. For example the DIE revision at address 0x1000005C. We use the write function to write a unique serial number to the UUT. We write the serial number as early as possible in the test in order to get a good traceability in the log. Then we program test hex file for testing the UUT. Then we need to erase the test software again to load the application software but without erasing the serial number. Therefore we need the erasepage function.

Related