"nrfjprog --program ..." resets the micocontroller without --reset option

[motters]

Hi,

Aim

We're trying to use nrfjprog on our pre-production line which requires the following steps:

1. Erase / Flash / Verify the program
   1. nrfjprog --clockspeed 8000 --verify --program {PATH} --chiperase --qspichiperase
2. Set device id in UICR
   1. nrfjprog --memwr 0x10001080 --val XXXXX
3. Disable debug control
   1. nrfjprog --memwr 0x10001210 --val 0xFFFF0000
4. Disable the reset pin
   1. nrfjprog --memwr 0x10001200 --val 0xFFFFFFFF
5. Turn on APPROTECT
   1. nrfjprog --memwr 0x10001208 --val 0xFFFFFF00
6. Reset / reboot the uC
   1. nrfjprog --reset

This process is fine when using MacOS.

Problem

However when using Windows the device is resetting / rebooting after programming (stage 1). This causes issues due to the way the device self commissions on first boot, without the device id (stage 2).

We have the same issue when using nrfconnect programming app with "auto reset" off. 

Attempts:

• This has been tested on two Window PCs with version 4.2.0.
• We've attempted to use an nrf52840 dev board and segger jlink as the programmer.

Do you have any suggestions?

[Einar Thorsrud]

Hi,

nrfjprog should not perform a reset unless you have provided an option for that. How do you see that a reset is performed, and which version do you use (both on windows and macOS)?

(nRF Connect for desktop is a different matter, as that is designed as a simple GUI programming tool but without production programming of high flexibility in mind.)

As a side note, if you need to work around this issue before it has been properly resolved, it should be possible to add a recover step as step 0 in your sequence, and swap the order of step 1 and 2 and remove --chiperase from step 1. That way, the UICR is programmed before your application runs for the first time, even if it runs before it should.

[motters]

On MacOS the reset is not performed [which is correct] (no matter how long we wait after programming), the version info is:

nrfjprog version: 10.17.0 external
JLinkARM.dll version: 7.92c

On Windows (2 PC have been tried; 2 programmers nordic dev board + Segger JLink) the following happens:

• Send the programming command
• Programming commands finishes
• For 2-4 seconds the device does not reboot
• The device then reboots

The version info for the windows PC is:

nrfjprog version: 10.24.0 external
JLinkARM.dll version: 7.94e

We'll test out the work around as well.

[Einar Thorsrud]

I am not able to reproduce on my end on macOS 14.3. As you are using a quite old nrfjprog on your Mac, can you try updating to the latest? It is paft of nRF Command Line Tools.

Also, note that this command probably does not do what you think it does:

nrfjprog --memwr 0x10001200 --val 0xFFFFFFFF

Pin reset is disabled by default, so generally there is no need to touch this register (but if you have firmware that enables pin reset runtime and you don't want that, you need to modify your firmware to not do it). And if pin reset had been enabled, this would not disable it, as you cannot flip bits from 0 to 1 by writing to flash. If you wanted to disable it by writing, you should write all 0's instead.

[motters]

Can you try and replicate it on Windows? As this is where the issues lies.

I have no problems with the MacOS version, it behaves correctly. I'm a bit wary right now of updating the mac as that is the working system atm. But we obviously want to use Windows on the product line not a Mac.

Ah thank you i will check this. The behaviour we want is to disable the rest pin on the device. Normally GPIO 18 (i think) is configured as the uC reset pin. I was hoping by setting  0x10001200, the pin could be default back to a gpio.

[Einar Thorsrud]

Hi,

Sorry, I was context switching and somehow forgot that you had issues on Windows. I am nota ble to reproduce on Windows either though (not even with 10.24.0 which is the same version you write), and have not seen any similar reports.

Can you try to specify other forms of reset to see if that matters? (like "nrfjprog --debugreset" or "nrfjprog --hardreset")?