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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Thu, 10 Jul 2025 06:56:38 GMT

I moved this question about the verify in a new case to close this here:

https://devzone.nordicsemi.com/f/nordic-q-a/122864/approtect-and-verify-with-nrfjprog

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Tue, 08 Jul 2025 15:38:22 GMT

I implemented now the suggested code on top of main:

void AppProtection(void)
{
#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){}
        NVIC_SystemReset();
   	}
#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){}
        NVIC_SystemReset();
	}
#endif
}

This is working, but the problem is that the verify in production programming is not working anymore. Is there an option to verify the chip before? Because after a program the chip is getting restarted and read out protection is active which makes verify impossible:

nrfjprog --program %HEX_FILE% --verify --log

[ #################### ]   6.201s | Program file - Done programming
[error] [ Client] - Encountered error -160: Command verify_file executed for 6382 milliseconds with result -160
[error] [  nRF52] - Failed while performing 'Verify' operation on target address 0x00027000.
-160: Data does not match in address range [0x00027000 - 0x000A42DA] (Flash)
Expected byte value 0x04 but read 0x85 at address 0x00035918.
[error] [  nRF52] - Failed while verifying device. -160: Data does not match in address range [0x00027000 - 0x000A42DA] (Flash)
Expected byte value 0x04 but read 0x85 at address 0x00035918.
[error] [ Worker] - Data does not match in address range [0x00027000 - 0x000A42DA] (Flash)
Expected byte value 0x04 but read 0x85 at address 0x00035918.
ERROR: Write verify failed.
Error occurred, errorlevel: 55

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Tue, 08 Jul 2025 12:32:57 GMT

Ok, so like I saw in this link:

[quote userid="107729" url="~/f/nordic-q-a/122632/nrf52840-qiaa-r-vs-nrf52840-qiaa-f-r/541759"] Implentation of Read-back protection on nRF52840 [/quote]

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.

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Priyanka — Tue, 08 Jul 2025 09:21:07 GMT

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Fri, 04 Jul 2025 09:42:57 GMT

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Priyanka — Fri, 04 Jul 2025 09:35:31 GMT

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Fri, 04 Jul 2025 09:21:39 GMT

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Thu, 03 Jul 2025 14:02:27 GMT

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Priyanka — Thu, 03 Jul 2025 12:47:33 GMT

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Thu, 03 Jul 2025 12:11:49 GMT

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?

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Priyanka — Thu, 03 Jul 2025 10:03:07 GMT

Hi Dominik,

[quote user="Dominik Eugster"]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.[/quote]

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

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Dominik Eugster — Tue, 01 Jul 2025 09:04:14 GMT

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.

RE: nRF52840-QIAA-R vs nRF52840-QIAA-F-R

Priyanka — Tue, 01 Jul 2025 08:51:17 GMT

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