Enable Access Port Protection in code - compatible with all three revisions of the IC

Hi,

I am working on a project that utilizes the nRF52832.

How to properly enable Access Port protection in the code, if I want to have a single firmware for all three revisions of the IC.

Currently, I have something like that:

#define NRF_IC_REVISION_1 (0x00000042) 
#define NRF_IC_REVISION_2 (0x00000045) 

static void enable_read_out_protection(void)
{
    uint32_t ic_variant = NRF_FICR->INFO.VARIANT;
    uint32_t build_code = ((ic_variant >> 8) & 0x000000FF);


    if ((NRF_IC_REVISION_1 != build_code) && (NRF_IC_REVISION_2 != build_code))
    {
        return;
    }

    // check if APPROTECT is already enabled.
    if (0xFFFFFF00 != NRF_UICR->APPROTECT)
    {
        // APPROTECT not set yet

        // program new value to APPROTECT
        nrf_nvmc_write_word((uint32_t)&(NRF_UICR->APPROTECT), 0xFFFFFF00);

        // trigger reset to apply new settings
        NVIC_SystemReset();
    }
}

Is the approach used to detect the revision of the IC ok?

  • Hi

    It looks like you're over engineering this a bit. The last revision of the nRF52832 has APPROTECT enabled by default, while the older have them open by default. However, you can use the same word to lock down the UICR.APPROTECT on all revisions of the nRF52832, so there's no need to worry about which revision is used.

    Is there a specific reason you want to detect the revision of the SoC you're working on? For that matter, almost all of the nRF52832 sold today are the rev 3 AFAIK, but of course, it's better to be safe than sorry.

    Best regards,

    Simon

  • Hi,

    thank you for the response.
    We are buying a third-party module with an nRF52832. I got a response from the supplier that revision 2 is currently installed on the module. And I also confirmed that by reading the revision directly from the module.

    I would like to have a future-proof solution so that we do not have to maintain two FW versions on the field, if the revision of the IC changes.

    So, If I understood correctly, I can freely remove the revision checking part?
    Will the programming of the NRF_UICR->APPROTECT to 0xFFFFFF00 work normally on the revision 3 and the IC will not be stuck in a dead loop of constant resets?

    Kind regards

  • Okay, I see. Thank you for the explanation.

    To answer your question, yes. If you write the word that locks the APPROTECT of older revisions, that should also lock revision 3 ICs. What makes you think it will be stuck in a reset loop?

    Best regards,

    Simon

  • Mostly, because I do not have a sample of revision 3 at hand to simply try it out and validate the solution.
    As I see, the nRF52 DK version 3.0.0 has  a QFAAG0 version of the IC. Maybe we will purchase a DK board and try the firmware on the board. As you said, better safe than sorry.

    Thank you for your support.

Related