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

Setting GPREGRET from pynrfjprog

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.

Parents
  • 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.

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

Reply
  • 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.

Children
No Data
Related