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
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
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.
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
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
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
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
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:
Implentation of Read-back protection on nRF52840
-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:
Implentation of Read-back protection on nRF52840
-Priyanka
Ok, so like I saw in this link:
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.
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