Hello,
System Details:
- Board: Custom
- Chip: nRF52833
- PCA Number: PCA10100
- SoftDevice: S140, v7
- nRF5 SDK: Version 16.0.0
- mdk version: 8.46.0
- nrfjprog version: 10.15.4 external
- JLinkARM.dll version: 7.64d
I recently made a Nordic DevZone post to get help working through the CTRL-AP access protection mechanism on my nRF52840 DK board (rev3) so that I could debug my project. The solution, among many other attempts, was to incorporate an approtect_hw_disable() function into my dfu/secure_bootloader/main.c file that would run on start up. This added function (along with the APPROTECT_HW_DISABLE preprocessor definition) is meant to disable approtect in UICR.APPROTECT at runtime in case the setting has been erased by the debugger. I have included it here (from this other post) for reference:
void approtect_hw_disable(void)
{
if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk)
== (UICR_APPROTECT_PALL_Msk))
{
NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}
NRF_UICR->APPROTECT = (UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos);
while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}
NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}
NVIC_SystemReset();
}
}
/**@brief Application main function.
*/
int main(void)
{
bool erase_bonds;
#if APPROTECT_HW_DISABLE
approtect_hw_disable();
#endif //APPROTECT_HW_DISABLE
I am now trying to program a new board, with the nRF52833 hardware. Unfortunately I am running into the same issue as last time, but now the previous solution is not working for me. I use a straightforward script to make 1) the dfu secure_bootloader for pca10100/s140, and 2) my custom application built on top of supported SDK examples (not all of which come with pca10100/140 support explicitly: ble_app_buttonless_dfu). The script then generates bootloader settings, and then attempts to flash everything onto my device. When I execute the script, all goes well, everything compiles and flashes successfully, but the moment my script finishes up and executes the final 'nrfjprog --reset' command, something goes wrong with the CTRL-AP access protection and I get locked out of the device and am forced to run 'nrfjprog --recover' in order to re-establish communication. This means I cannot debug my device/project using the SEGGER Embedded Studio debugger like usual... Also, I make sure to explicitly write the value 0x5A to address 0x10001208, and this write persists on the device until the moment I run the 'nrfjprog --reset' command, and everything gets erased. Here is the script for your reference:
#! /bin/bash
# nRF52833
## Compile bootloader and application:
boot_make='../nrf-sdk/examples/dfu/secure_bootloader/pca10100_s140_ble/armgcc/'
boot=${boot_make}_build/nrf52833_xxaa_s140.hex
softdevice='../nrf-sdk/components/softdevice/s140/hex/s140_nrf52_7.0.1_softdevice.hex'
app_make='../nrf-sdk/examples/ble_peripheral/ble_app_technolingus/pca10100/s140/armgcc/'
app=${app_make}_build/nrf52833_xxaa.hex
make -C "$boot_make"
make -C "$app_make"
nrfutil settings generate --family NRF52 --application "$app" --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex
nrfjprog --recover
nrfjprog -e
nrfjprog --memwr 0x10001208 --val 0x5a
nrfjprog --memrd 0x10001208
nrfjprog --program "$softdevice" --verify
nrfjprog --program "$boot" --verify
nrfjprog --program "$app" --verify
nrfjprog --program settings.hex --verify
nrfjprog --reset
Any ideas as to why this CTRL-AP mechanism keeps enabling itself? Is there a way that I can stop this behavior in general? Thank you for your patience with me, and thanks in advance for your help here.
Best,
Corten
