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.

[Gili Elias]

You are right. The register is set to 1 correctly (even without erasing the chip). This means the reset isn't issued correctly. If I use the API only to set GPREGRET to 1 and restart with "nrfjprog -r" then I get the correct sequence. Our code reads the GPREGRET on reset and sets it to 0, so it should be 0 a few ms after reset. Calling api.sys_reset() does not have any effect. GPREGRET remains 1. api.pin_reset() does work, but it clears the GPREGRET before, so we can't use it.

[Michael Dietz]

Hey,

Short answer: pynrfjprog issues a system reset but it does not run the CPU after the reset and after you call api.sys_reset() your application never runs! So you need to call something like api.go() after the sys_reset() and I think it will work.

Long: pynrfjprog is basically a wrapper for our nrfjprog dll - nothing more, nothing less. And what you discovered is a problem with the nrfjprog dll that we have been working on - side effects. Basically some functions in nrfjprog leave the CPU in a certain (unexpected to the user) state. What you saw here is that calling system_reset() left your CPU halted! We realize this is a problem and in our latest release we documented this in the dll header file.

nrfjprog.exe is more user facing so you don't really have to worry about this (although this has caused some problems before..) Please keep this in mind when using pynrfjprog or DLL

[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.

[Gili Elias]

Again, you are right. I've added api.go() after the reset and it worked. I'll make sure to dig more through the header file next time. Thank you!