Access port protection nrf52840 rev3 vs rev2

Hi, 

As we are updating the SDK and S140 SD used in our project from SDK17.0.2   SD 7.2.0   to   SDK 17.1.0  SD 7.3.0 we have a concern about the differences in the  APPROTECT management.

Especially on the added changes mentioned in nRF52840 Revision 3 Errata ([249] DIF: Access port protection needs software interface configuration)
, about which, If I correctly understood, brings a workaround to issue described in  Product Change Notification (nordicsemi.com).  (Please correct me if I'm wrong.)


At the moment we are developing and producing our device with nrf52840 rev 2   and  will soon change it to rev 3. 

Main question is the following:  
Is the mechanism implemented in  "static inline void nrf52_handle_approtect(void)" provided in MDK 8.40.3 in header file "system_nrf52_approtect.h" expected to work on nrf52840 rev 3 only, or is it supposed to work for rev 2 as well ?

The reason of the question is that at the moment we only have devices with rev 2 available and we use the "legacy code"  which still works as expected. after SDK and SD update => Good News. 

...
// Enable readout protection
if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) == (UICR_APPROTECT_PALL_Disabled << UICR_APPROTECT_PALL_Pos))
{
    uint32_t tmp;
    /* Enable access to write to flash */
    NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos);
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

    /* Enable Access Port Protection. Access to CPU registers and memory will be disabled
       to disable protection ERASEALL command must be applied. */
    tmp                 = NRF_UICR->APPROTECT & ~UICR_APPROTECT_PALL_Msk;
    NRF_UICR->APPROTECT = tmp | (UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos);
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy) { }

    /* Disable access to write to flash */
    NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos);
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}

    /* Perform reset to take effect of changes */
    NVIC_SystemReset();
}
...

but when we replace it by:

static inline void nrf52_handle_approtect(void)
{
    #if NRF52_ERRATA_249_PRESENT
        #if defined (ENABLE_APPROTECT)
            if (nrf52_errata_249())
            {
                #error forceprotect
                /* Prevent processor from unlocking APPROTECT soft branch after this point. */
                NRF_APPROTECT->FORCEPROTECT = APPROTECT_FORCEPROTECT_FORCEPROTECT_Force;
            }
        #else
            if (nrf52_errata_249())
            {
                /* Load APPROTECT soft branch from UICR.
                   If UICR->APPROTECT is disabled, POWER->APPROTECT will be disabled. */
                NRF_APPROTECT->DISABLE = NRF_UICR->APPROTECT;
            }
        #endif
    #endif
}

with the appropriate definitions:  NRF52_ERRATA_249_PRESENT / ENABLE_APPROTECT, devices are always readable.

Does it mean that for the integration of rev3 in our product, we will have to manage 2 different firmware ? 
 
We are looking forward to your answer and advice. 

Kind Regards 

Raphael




  • Hi Raphael, Ill have to double check this and will be back to you most by Monday.

  • Hi Raphael,

    On older devices (rev 2 and rev1) you still need to the below that you are doing and NOT replace it with new nrf52_handle_approtect to enable the readback protection.

    On newer devices (rev 3) readback is enabled by default on startup and using the nrf52_handle_approtect you can decide to have forceprotect or not by adding/not_adding the flag ENABLE_APPROTECT in your application.

    Does it mean that for the integration of rev3 in our product, we will have to manage 2 different firmware ? 

    You can have both code handling for both your versions to simply your version handling.

    Code snippet 1) 

    ...
    // Enable readout protection
    if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) == (UICR_APPROTECT_PALL_Disabled << UICR_APPROTECT_PALL_Pos))
    {
        uint32_t tmp;
        /* Enable access to write to flash */
        NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos);
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
    
        /* Enable Access Port Protection. Access to CPU registers and memory will be disabled
           to disable protection ERASEALL command must be applied. */
        tmp                 = NRF_UICR->APPROTECT & ~UICR_APPROTECT_PALL_Msk;
        NRF_UICR->APPROTECT = tmp | (UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos);
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy) { }
    
        /* Disable access to write to flash */
        NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos);
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}
    
        /* Perform reset to take effect of changes */
        NVIC_SystemReset();
    }
    ...

    Code snippet 2)

    static inline void nrf52_handle_approtect(void)
    {
        #if NRF52_ERRATA_249_PRESENT
            #if defined (ENABLE_APPROTECT)
                if (nrf52_errata_249())
                {
                    #error forceprotect
                    /* Prevent processor from unlocking APPROTECT soft branch after this point. */
                    NRF_APPROTECT->FORCEPROTECT = APPROTECT_FORCEPROTECT_FORCEPROTECT_Force;
                }
            #else
                if (nrf52_errata_249())
                {
                    /* Load APPROTECT soft branch from UICR.
                       If UICR->APPROTECT is disabled, POWER->APPROTECT will be disabled. */
                    NRF_APPROTECT->DISABLE = NRF_UICR->APPROTECT;
                }
            #endif
        #endif
    }

    • Code snippet 2, will not have any influence on rev2 chips as this part of the registers are not implemented and hence writing to them is allowed but will not do anything.
    • Code snippet 1, can still be used on rev 3 and will be usable when handling nrf52_handle_approtect when ENABLE_APPROTECT is not set in your project. 

    In short, you still can have same firmware and use both the above mentioned handling in both revision of the chips.

  • Hi Susheel, 

    Thank you very much for your answer, quite clear.

    Kind  Regards


Related