nRF52840-QIAA-R vs nRF52840-QIAA-F-R

[Dominik Eugster]

Hi

We are using the nRF52840-QIAA-R in a lot of PCBA, now I see there is a new revision nRF52840-QIAA-F-R and the old type is not recommended for new design.

What is the difference between the 2 types and are they 100% compatible? Where can I see the difference between the old and the new type?

Thank you

[Priyanka]

Hi Dominik,

Please find the Product Change Notification (PCN) Information for nRF52840-QIAA to nRF52840-QIAA-F here:

https://docs.nordicsemi.com/bundle/PCN/resource/pcn_162_v1.0.pdf 

You can find the various PCN data here:

https://docs.nordicsemi.com/search?rpp=10&labelkey=nrf52840&labelkey=product-change-notification 

Regards,

Priyanka

[Dominik Eugster]

Thank you, but there the change is only pointing on the ESD specifications:

This is the reason for NRND?

Because here it's written that the access port protection is controlled by software and ahrdware, what this means? This has nothing to do with ESD.

[Priyanka]

Hi Dominik,

Dominik Eugster said:

Because here it's written that the access port protection is controlled by software and ahrdware, what this means? This has nothing to do with ESD.

Sorry for the confusion. That doesn't have anything to do with ESD. That's just an extra protection layer added from revisions Fxx onwards. You can take a look here: https://docs.nordicsemi.com/bundle/ps_nrf52840/page/dif.html#d402e184 

From revisions Fxx onwards this APPROTECT via hw and sw is the change that has happened compared to the other revisions. So we recommend using these now.

The PCN I attached affects both  nRF52840-QIAA and  nRF52840-QIAA-F chips which have specific build codes:

Sorry for the confusion. I assumed you were talking about build codes and hence attached this.

-Priyanka

[Dominik Eugster]

ok, thank you for clarification, so the recommended part number would be Fxx, which means the chip with D0 should not be used and have a security issue? Or can be used with a BugFix?

[Priyanka]

Hi Dominik,

Here is what the writings on the SoC mean:

nRF52840 - The name of the product

QIAAD0 MEANS:

QI (the type of packaging)

AA (controlled by hardware) & if it's AA-F (controlled by hardware & software)

D0 are just hardware version codes and production version codes (again, do not worry about this).

The PCN is for the reference of distributors and not the customers so you don't have to worry about it or look at it

(You cannot see the build codes on the SoC as the build codes are written on the package that you order the SoC in).

All you have to make sure is that you do not use an SoC which is as shown in the picture you attached, because it is QIAA and not QIAA-F.

For reference I can attach what the recommended SoC nowadays looks like:

Hope this clarifies your doubts.

You can find more information regarding these here: https://docs.nordicsemi.com/bundle/ps_nrf52840/page/ordering_info.html 

-Priyanka

[Dominik Eugster]

ok, but when I have nRF52 like in my picture which work-around I have to do or which I have to keep in mind regarding the difference to the -F version? We have a running production with the "old chips" which are like in my picture. The next production we can use the -F version but the actual stock we have to use.

I can't find the issues in the errata with the version D0 compared to -F, can you please highlight this.

Thanks a lot

[Dominik Eugster]

Priyanka 
coming back to this topic, I saw in this article how we should handle the APPPROTECT:

Working with the nRF52 Series' improved APPROTECT

So my understanding is the following:

The -F revisoon of the nRF52840 is enabling this in hardware?

The old revision we are using this feature we have to enable in Firmware. We are running the system with a boatloader and in the production flashing we use this line:

nrfjprog --rbp ALL

We are using the nRF secure_ble_bootloader.

There i saw this line function, enabled when NRF_BL_DEBUG_PORT_DISABLE is true:

void nrf_bootloader_debug_port_disable(void)
{
    if (NRF_UICR->APPROTECT != 0x0)
    {
        nrf_nvmc_write_word((uint32_t)&NRF_UICR->APPROTECT, 0x0);
        NVIC_SystemReset();
    }
#if (!defined (NRF52810_XXAA) && !defined (NRF52811_XXAA) && !defined (NRF52832_XXAA) && !defined (NRF52832_XXAB))
    if (NRF_UICR->DEBUGCTRL != 0x0)
    {
        nrf_nvmc_write_word((uint32_t)&NRF_UICR->DEBUGCTRL, 0x0);
        NVIC_SystemReset();
    }
#endif
}

So if I enable NRF_BL_DEBUG_PORT_DISABLE in SDK config of the bootloader, the chip is staring the bootloader, checking if NRF_UICR->APPROTECT is not 0x0 and will set NRF_UICR->APPROTECT to 0x0 followed by a NVIC_SystemReset.

The MCU is restarting, check the NVIC_SystemReset again, the value is 0, the bootloader is checking for a new bootloader file and if there is nothing to do it will switch to the application.

I modified the booloader to flash from an external QSPI flash in parallel with the original BLE bootloader.

In case of a firmware update the register nrf_power_gpregret_get is used. After resetting the device the value in this register is getting lost. Is the setting in nrf_nvmc_write_word((uint32_t)&NRF_UICR->APPROTECT, 0x0); permanent? (after a system reset?)

For sure I will add the AppProtect in the application:

-> The most effective way to ensure that UICR.APPROTECT is set correctly is probably to verify it in the application. For example, the following code snippet could be added to the top of main:

#ifdef ENABLE_APPROTECT
	if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) !=
		(UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos)) {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->APPROTECT = ((NRF_UICR->APPROTECT & ~((uint32_t)UICR_APPROTECT_PALL_Msk)) |
		    (UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos));

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
   	}
#else
	if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) !=
		(UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos)) {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->APPROTECT = ((NRF_UICR->APPROTECT & ~((uint32_t)UICR_APPROTECT_PALL_Msk)) |
		    (UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos));

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
	}
#endif

Is there something to add in the bootloader aswell expection enabling the NRF_BL_DEBUG_PORT_DISABLE in SDK_config?

Is this how the protection should be implemented on nRF52840-QIAA-R and nRF52840-QIAA-F?

Thank you for clarification

[Priyanka]

For the already done products, you don't need to do any changes.

The only difference between the versions, as mentioned before, is the APPROTECT enabled in hardware and software too for the QIAA-F series. So for the new series, you will have to recover the chip each time before you re-flash the chip. So from the next production onward, you can use the QIAA-F series.

No problem in using the old chips in your current production.

-Priyanka

[Dominik Eugster]

But if we are using: 

nrfjprog --rbp ALL

in the old chip revisions, this additional function is "nice to have" and not necessary?

#ifdef ENABLE_APPROTECT
	if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) !=
		(UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos)) {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->APPROTECT = ((NRF_UICR->APPROTECT & ~((uint32_t)UICR_APPROTECT_PALL_Msk)) |
		    (UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos));

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
   	}
#else
	if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) !=
		(UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos)) {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->APPROTECT = ((NRF_UICR->APPROTECT & ~((uint32_t)UICR_APPROTECT_PALL_Msk)) |
		    (UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos));

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
	}
#endif

[Priyanka]

Yes, that should be right. For new devices, both hardware and software methods are recommended, but for old devices, the hardware method alone is enough.

You can go through the following references too:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/working-with-the-nrf52-series-improved-approtect#mcetoc_1fr480n9d1 

 Implentation of Read-back protection on nRF52840 

-Priyanka 

[Dominik Eugster]

Ok, so like I saw in this link: 

Priyanka said:

 Implentation of Read-back protection on nRF52840 

CONFIG_NRF_APPROTECT_LOCK should be set. Is this working also with nRF5 SDK v17.1.0?

But in sdk_config.h this option doesn't exists and I can't find it in some header or c file.