Reset after updating UICR (NVIC_SystemReset() doesn't seem to be enough)

[Visti Andresen]

In our application we need to have the NFC pins configured for GPIO and APPROTECT enabled.

As an additional safety feature I verify the UICR content inside my application (as OTA DFU packages seems to be stripped of any UICR bits)
After updating UICR one needs to reset the nRF52, from the nrf52832 data sheet: "After UICR has been written, the new UICR configuration will only take effect after a reset."

I can verify that I changed the UICR content (enabling APPROTECT) by reading it before and after the flash operation.
However after calling NVIC_SystemReset(); I can still read back flash content using nrfjprog.
(After a power cycle the protection is enabled as expected)

I suspect that NVIC_SystemReset() doesn't cause a reset as such, but more likely just restarts the chip by jumping according to the interrupt vector table.

Note:
The hardware is using the using P0.21 as a GPIO pin.
And I'm using nRF5_SDK_14.2.0_17b948a with s132_nrf52_5.1.0_softdevice.hex
The test is performed with an attached J-link programmer and a running gdb instance 

Is there another way to reset the nRF52 that will cause a reread of the UICR data, perhaps using the watchdog?

Regards Visti Andresen

[Kenneth]

Hi,

I do not expect that NVIC_SystemReset() will work, however can you use nrfjprog instead, for instance run: 'nrfjprog --rbp all' to apply approtect. You may also try 'nrfjprog -r".

Best regards,
Kenneth

[Visti Andresen]

Yes however as the application check is intended to be done while in the hands of the end user this isn't an option.

The current production bootloader is flashed with APPROTECT enabled.
(and production flashing performs a reset prior to verifying that it is no longer possible to read flash memory back)

The purpose for the additional check is that:
A) We have a few older unprotected devices and since the DFU packages seems to be stripped of the UICR bits they can't be protected by a OTA DFU update.
B) In any cases where the UICR bits isn't set as we desire, we can reprogram the UICR memory.

And after programming the UICR memory it would be nice to some how cause a reset (in software) that caused the new UICR values to be used.

Regards Visti Andresen

[Kenneth]

Hi,

Just to make sure I understand what you are doing:

1. You have a device that is not connected to a J-Link programmer.

2. The firmware of the device write to APPROTECT.

3. The firmware of the device does a soft reset.

To find out if APPROTECT works you now do:

4. You connect a J-Link programmer to the SWD port and you are able to read out firmware?

Best regards,
Kenneth

[Visti Andresen]

1 to 3 is the desired effect (but not the used test setup)

The test setup (J-link only attached to verify the process and as a easy means of flashing a broken bootloader):

1. Connected J-Link flashes intentionally broken bootloader (without APROTECT) and an application that is supposed to correct the UICR data.
This is done with a running JLinkGDBServer and JLinkRTTClient.

2. The application code is monitored using the RTT link and NRF_LOG_INFO macro calls, and has been found to detect the 0xFFFFFFFF in APPROTECT, and it flashes 0xFFFFFF00 which is verified by reading it back from flash.

3. The application code issues a NVIC_SystemReset();

4. After this it is possible to read back flash content using nrfjprog.

I'm therefor looking for a better way of performing a reset in application code for step 3

[Kenneth]

My opinion is that if j-link is already attached (in other words the chip is in debug mode), then only a power on reset, brown out reset or pin reset will ensure you load APPROTECT as you want. 

Best regards,
Kenneth