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]

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.

[Dominik Eugster]

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