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?

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

[emlynkz]

I am asking this question for when this project goes into production.

Our standard production workflow with v2 chips was to perform a eraseall of the flash, then flash our .hex with all the firmware on it.

What change in my firmware can I make that will disable APPROTECT? This is to be used with prototypes on which we want debug access, but still run them through the production workflow.

[Vidar Berg]

You can try the code snippet I posted here  RE: Trying to disable APPROTECT for debugging . This will disable the HW part of the approtect mechanism by writing 0x5A to the UICR.APPROTECT register on first boot.

emlynkz said:

Our standard production workflow with v2 chips was to perform a eraseall of the flash

Note that the ERASEALL must be performed via the CTRL-AP - Control access port on the new revision.