Setting GPREGRET from pynrfjprog

[Gili Elias]

Hi, We have an application that can run in two modes. The mode is selected by setting the GPREGRET to 1 or 0 and restarting. Currently we are running this procedure directly via jlink commander, but we want to convert it to python commands. Using the nrfjprog cmd line tool, it works OK:

nrfjprog.exe --memwr 0x4000051C --val 1
nrfjprog.exe -r

Using the python API doesn't work:

    api = API.MultiAPI(API.DeviceFamily.NRF51)
    api.open()
    api.connect_to_emu_with_snr(serial_number)
    api.write_u32(0x4000051C, 0x01, True)
    api.sys_reset()
    api.disconnect_from_emu()
    api.close()

The device is a PCA10031 with softdevice s120. The python API version is 8.4.0 along with Jlink 5.10t.

[Michael Dietz]

Hi Gili,

Using the same pynrfjprog and J-Link versions and the PCA10031 board I am able to write the GPREGRET register as 0x01 with the pynrfjprog commands you used above and correctly read it back as 0x01.

However I don't have a SoftDevice or Application programmed on the board.

I'm wondering if there is some interference between pynrfjprog and your SoftDevice/application. But can you verify that you can correctly write this register when the chip is erased?

See comments below for answer and important information about 'side effects' the nrfjprog DLL introduces.

[Michael Dietz]

These are documented in the @pre, @during and @post tags in the header file comments above each function declaration in nrf5x_nrfjprogdll.h that you will find here 'C:\Program Files (x86)\Nordic Semiconductor\nrf5x\bin\headers.'

Most likely this won't be a problem you run into often when using pynrfjprog but in this you did.. If you see strange behavior in the future this could be one of your suspects and then you could check the header file to verify.