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

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

Einar Thorsrud — Thu, 01 Feb 2024 09:35:25 GMT

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

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

motters — Wed, 31 Jan 2024 16:53:41 GMT

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.

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

Einar Thorsrud — Wed, 31 Jan 2024 14:32:47 GMT

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.

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

motters — Wed, 31 Jan 2024 10:54:27 GMT

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.

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

Einar Thorsrud — Tue, 30 Jan 2024 12:34:30 GMT

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.