Enabling AP-PROTECT not consistent

RE: Enabling AP-PROTECT not consistent

ernieforzano — Mon, 12 Feb 2024 16:27:15 GMT

You must also include the following configuration otherwise there will be a linker issue:

CONFIG_NRFX_NVMC=y

RE: Enabling AP-PROTECT not consistent

Sigurd Hellesvik — Mon, 12 Feb 2024 09:12:36 GMT

Based on some feedback from a colleague, here is an improved version:

#include <nrfx_nvmc.h>
#include <zephyr/kernel.h>

int main(void)
{
  k_sleep(K_MSEC(10));

  uint32_t approtect_status = nrfx_nvmc_uicr_word_read((uint32_t)&NRF_UICR->APPROTECT) & UICR_APPROTECT_PALL_Msk;
  if(approtect_status == UICR_APPROTECT_PALL_Disabled) {
    while (!nrfx_nvmc_write_done_check()) 
      ;
    nrfx_nvmc_word_write((uint32_t)&NRF_UICR->APPROTECT, UICR_APPROTECT_PALL_Enabled);
    while (!nrfx_nvmc_write_done_check()) 
      ;
        NVIC_SystemReset();
  }
    printk("Hello World! %x\n", approtect_status);
    return 0;
}

RE: Enabling AP-PROTECT not consistent

ernieforzano — Fri, 09 Feb 2024 16:23:42 GMT

Thank you so much for following up Sigurd!! This was much appreciated.

RE: Enabling AP-PROTECT not consistent

Sigurd Hellesvik — Thu, 08 Feb 2024 15:43:29 GMT

[quote user="ernieforzano"]In the future if you check revision, that would be awesome to prevent extra step for production.[/quote]

ernieforzano I must correct myself. I learned now that you can indeed enable APPROTECT for old nRF52 revisions from the code. You just have to do it manually.

I hope that this is not too late.

Try this:

#include <zephyr/kernel.h>
#include <nrfx_nvmc.h>

static void config_nvmc(uint32_t val)
{
  while (!NRF_NVMC->READY);
  NRF_NVMC->CONFIG = val;
  while (!NRF_NVMC->READY);
}

void main(void)
{
  config_nvmc(1);
  NRF_UICR->APPROTECT = 1;
  config_nvmc(0);
  printk("Hello World! %x\n", NRF_UICR->APPROTECT);
  /* k_sleep(K_SECONDS(2)); */
  /* printk("erasing\n"); */
  /* nrfx_nvmc_all_erase(); */
  /* printk("after erase\n"); */
}

RE: Enabling AP-PROTECT not consistent

ernieforzano — Thu, 25 Jan 2024 15:48:59 GMT

Awesome thanks for the update.

In the future if you check revision, that would be awesome to prevent extra step for production.

Thanks for the support.

RE: Enabling AP-PROTECT not consistent

Sigurd Hellesvik — Thu, 25 Jan 2024 10:54:41 GMT

[quote user="Sigurd Hellesvik"]Still, setting CONFIG_NRF_APPROTECT_LOCK should lock the device by default, no matter which chip you have I think. If not, the setting should let you know if it does not work.[/quote]

From the docs, Open is the only option for "Hardware Approtect" only devices.
For the nRF52840DK, there is no way to detect which revision you have for the build system, so we can unfortunally not give a warning on this.

EDIT: added DK, cause I think zephyr technically has knowledge about chip revisions. So it is not "no way to detect it".

Second EDIT: Zephyr does not know about revisions, it knows about package types, which is not the same

So yea, you can not use the LOCK option on old revision.

[quote user="ernieforzano"]

It does not seem to give any feedback when flashing. When I read the firmware after flashing it in NRFConnect, I can see that:

Readback protection status: NRFDL_PROTECTION_STATUS_NONE

Whenever I program the nRF52840 with the UICR CONFIG_NRF_APPROTECT_USE_UICR=y it works after you run the command nrfjprog --rbp ALL. I can see that status change.

Let me know if I am missing something.

[/quote]

Looks right to me.

RE: Enabling AP-PROTECT not consistent

ernieforzano — Tue, 23 Jan 2024 18:28:59 GMT

Hi Sigurd!

Ah! That makes sense. My revision is Dx0. So that would explain why it might not work.

It does not seem to give any feedback when flashing. When I read the firmware after flashing it in NRFConnect, I can see that:

Readback protection status: NRFDL_PROTECTION_STATUS_NONE

RE: Enabling AP-PROTECT not consistent

Sigurd Hellesvik — Tue, 23 Jan 2024 09:17:20 GMT

[quote user=""]CONFIG_NRF_APPROTECT_LOCK=y it works for only the NRF5340 and not the NRF52840. [/quote]

I missed the "not" part for the nRF52840 here.
We have two different versions of approtect on the nRF52840, and this depends on which revision you have. From Working with the nRF52 Series' improved APPROTECT :

"
New revisions of nRF52805 (revision 2, build codes Bx0), nRF52810 (revision 3, build codes Ex0), nrf52811 (revision 2, build codes Bx0), nRF52820 (revision 3, build codes Dx0), nRF52833 (revision 2, build codes Bx0), nRF52832 (revision 3, build codes Gx0), and nRF52840 (revision 3, build codes Fx0) include an improved implementation of the the access port protection mechanism.
"

From Approtect: Implementation overview:

Here, 1 is the devices without the improved implementation, and 2 is the devices with the improved implementation.

And nRF5340 is 2. So my guess is that you see different behaviour between the nRF52840 and nRF5340 because the nRF52 revision you have does 1 and nRF53 does 2.

Still, setting CONFIG_NRF_APPROTECT_LOCK should lock the device by default, no matter which chip you have I think. If not, the setting should let you know if it does not work.

[quote user="ernieforzano"]This worked with the nRF53 but not the nRF52. Let me know if I am missing something. [/quote]

I will do some testing and see if I can reproduce this.

Which revision is your nRF52? You can read that from the top of the SoC.

RE: Enabling AP-PROTECT not consistent

ernieforzano — Mon, 22 Jan 2024 15:06:29 GMT

Hi Sigurd!

I read that documentation and I believe for the CONFIG_NRF_APPROTECT_LOCK all you need to do is include this Kconfig and compile it.

Setting the CONFIG_NRF_APPROTECT_LOCK Kconfig option to y and compiling the firmware is enough to enable the access port protection mechanism for SoCs of the nRF53 Series and those SoCs of the nRF52 Series that feature the hardware and software type of AP-Protect. The access port protection configured in this way cannot be disabled without erasing the flash.

This worked with the nRF53 but not the nRF52. Let me know if I am missing something.

RE: Enabling AP-PROTECT not consistent

Sigurd Hellesvik — Mon, 22 Jan 2024 10:13:47 GMT

See Enabling access port protection mechanism docs.Then let me know if you still have questions.

Regards,
Sigurd Hellesvik