• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 63 subscribers
  • Views 4201 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 285643
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Trying to disable APPROTECT for debugging

mrono

Hi.

I have received my first nRF52 device that has the new and improved APPROTECT mechanism, and I'm having a hard time disabling the protection for debugging.

I have read this guide, but can't seem to disable the protection. Whenever I reset the device, it is locked again.

The device is an nRF52833, build code B00 by the markings. I have updated nRF command line tools to version 10.15.4. I'm building my firmware using Keil uVision, and have updated the MDK to version 8.44.1. The firmware does not have ENABLE_APPROTECT defined anywhere I can find.

Here is a log from the command line where I'm programming the device and trying to connect after a reset. The firmware is a variant of the secure bootloader, which does work. I just can't connect to the device afterwards to debug.

Can anyone see what I'm doing wrong?

C:\>nrfjprog --version
nrfjprog version: 10.15.4 external
JLinkARM.dll version: 7.58b

C:\>nrfjprog --family NRF52 --recover
Recovering device. This operation might take 30s.
Writing image to disable ap protect.
Erasing user code and UICR flash areas.

C:\>nrfjprog --family NRF52 --memrd 0x10001208
0x10001208: 0000005A |Z...|

C:\>nrfjprog --family NRF52 --program HWv4_BLv8.hex --verify --sectorerase
Parsing image file.
Verifying programming.
Verified OK.

C:\>nrfjprog --family NRF52 --memrd 0x10001208
0x10001208: 0000005A |Z...|

C:\>nrfjprog --family NRF52 --reset
Applying system reset.
Run.

C:\>nrfjprog --family NRF52 --memrd 0x10001208
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

C:\>nrfjprog --family NRF52 --recover
Recovering device. This operation might take 30s.
Writing image to disable ap protect.
Erasing user code and UICR flash areas.

C:\>nrfjprog --family NRF52 --memrd 0x10001208
0x10001208: 0000005A |Z...|

C:\>nrfjprog --family NRF52 --program HWv4_BLv8.hex --verify --sectorerase
Parsing image file.
Verifying programming.
Verified OK.

C:\>nrfjprog --family NRF52 --memrd 0x10001208
0x10001208: 0000005A |Z...|

C:\>nrfjprog --family NRF52 --memwr 0x10001208 --val 0x5A
Parsing parameters.
WARNING: Writing to a non-empty address may result in unexpected behavior.
Would you like to continue with the operation? [Y]/N y
Writing.

C:\>nrfjprog --family NRF52 --reset
Applying system reset.
Run.

C:\>nrfjprog --family NRF52 --memrd 0x10001208
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

  • 0

    Hello,

    Does the 'HWv4_BLv8' image include data in the UICR region? If it does, then the --sectorerase option will cause the entire UICR region to get erased, including the APPROTECT register at 0x10001208.

    As a test, please try with this sequence and see if it gives the same result:

    $ nrfjprog --recover

    $ nrfjprog --eraseall

    $ nrfjprog --memwr 0x10001208 --val 0x5a

    $ nrfjprog --program HWv4_BLv8.hex --verify -r

    $ nrfjprog --memrd --memrd 0x10001208

    Alternatively, try call this function at the beginning of main() to disable approtect in UICR.APPROTECT at runtime in case if the setting has been erased by the debugger:

    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

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg
    Vidar Berg said:
    Does the 'HWv4_BLv8' image include data in the UICR region?

    It is essentially the BLE secure bootloader adapted to my hardware plus the s113 softdevice.

    Vidar Berg said:
    If it does, then the --sectorerase option will cause the entire UICR region to get erased, including the APPROTECT register at 0x10001208.

    In the log above I'm reading that register after the programming. And it is still 0x5A. Could this still be the case?

    Vidar Berg said:
    As a test, please try with this sequence and see if it gives the same result:

    That sequence results in the same outcome. Curiously even after eraseall the APPROTECT register set to 0x5A, before the memwr in your sequence. Is this normal? Or is the erase for some reason not working? Everything nrfjprog prints suggests all command succeeded.

  • 0 in reply to Vidar Berg
    Vidar Berg said:
    Alternatively, try call this function at the beginning of main()

    I added that to the beginning of the bootloader, as well as my test application. Still no access with the debugger after reset.

    And both the bootloader and the test application are running. I even used the bootloader to update the application.

    Is this an issue with my J-Link perhaps? But it clearly can do the recovery process.

  • +1 in reply to mrono
    mrono said:
    In the log above I'm reading that register after the programming. And it is still 0x5A. Could this still be the case?

    Sorry, I missed that part. So no, it's not the issue I initially thought it was. But I think I know what it is now - mdk 8.44.1 had a bug that would cause the if statement here to be evaluated as 'false' for all nRF52833 revisions: https://github.com/NordicSemiconductor/nrfx/blob/0805a0bce623775a26e2ef1b0acc070d68d1b6d7/mdk/system_nrf52_approtect.h#L51. Thus, preventing the program from disabling approtect in SW.

    This has been is fixed in v8.44.2:

  • 0 in reply to Vidar Berg

    That was it. Now I have debug access.

    Thank you.

Related

core_v2_widget.Hide()