nrf52 DK keeps resecuring itself

[emlynkz]

Hi,

I have just acquired a new nRF52 DK devkit.

Performing a `nrfjprog --recover` followed by `nrfjprog --eraseall` doesn't work to remove the protection.

I do not flash a new firmware on it. After a power cycle, I need to recover and erase the MCU again to connect to it via RTT.

Any idea how to fix this?

Thanks,

Étienne Machabée
Lynkz Instruments Inc.

[byte]

Hello Étienne,  

This looks very similar to the problem I'm having although I have an nrf5340 project. This started happening to me after I upgraded from nrf connect v2.7.0 to nrf connect v2.9.0. Are you also using nrf connect v2.9.0?

Rob

[Vidar Berg]

Hi,

The way the APPROTECT mechanism works is that both the non-volatile UICR.APPROTECT register and the volatile APPROTECT.DISABLE register need to be set to the same unlock value (0x5A on the nRF52 series) to disable it (Access port protection controlled by hardware and software). The latter register must be written to by the CPU on boot. This means APPROTECT will be enabled again if you erase and reset the chip.

The nrfjprog --recover operation performs a chip erase, then loads a small firmware binary that writes to the APPROTECT.DISABLE register to ensure APPROTECT remains disabled. This FW will be deleted when you call `nrfjprog --eraseall` after the recover. 

Which SDK and SDK version are you using?

byte said:

This looks very similar to the problem I'm having although I have an nrf5340 project. This started happening to me after I upgraded from nrf connect v2.7.0 to nrf connect v2.9.0. Are you also using nrf connect v2.9.0?

Apart from approtect being enabled, does the FW work as expected? Also, do you get the warning about approtect when trying to program the appcore or the netcore?

[emlynkz]

Hi Vidar,

I usually develop on ANNA-B112 chips and I have never had issues with that. Is it a new hardware revision that changed that?

On my custom boards I can flash the same firmware without an issue of it securing itself.

I'm using nRF5 SDK v16.

[Vidar Berg]

Hi,

Yes, there is a new silicon revision, please see the IN-142 for more information. The startup files included in nRF5 SDK v16 is not compatible with this HW revision, but those in v17.1.0 are.

[emlynkz]

Hi Vidar,

thanks for the info.

Upgrading all our projects to nRF5 SDK v17.1.0 is a big endeavour as it breaks a couple of things.

Is there a workaround that can be used with nRF5 SDK v16?

Thanks!

[Vidar Berg]

You can update the startup files (part of the MDK package) for you existing projects and rebuild the FW binaries for this revision. We still manufacture and sell the old revision, so another possibility for you may be to use the old ordering code and buy revision 2 chips. 

[emlynkz]

Good, I'll look into that.

Thanks!

[emlynkz]

Hi Vidar,

I have rebuilt my project using the v17.1.0 nRF5 SDK and I keep having the same issue when I do an erase all. Can I have my project set the configuration for the APPPROTECT instead of having nrfjprog --recover do it?

What else do I need to change to my previously working project for it to not secure itself on the new devkit that came with a revision 3 chip?

Thanks.

[Vidar Berg]

Hi,

When are you erasing the flash? Performing an eraseall will remove any firmware on the device that can unlock the software part of the approtect during boot. This means that APPROTECT will be enabled again after a power cycle of the board.