• State Verified Answer
  • Replies 2 replies
  • Subscribers 86 subscribers
  • Views 1015 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 350879
Options

Debug port access port protection disabled after firmware wrote NRF_APPROTECT.DISABLE with 0

Anthony Ambuehl

I am trying to implemented a mechanism for authenticated debug on NRF52840 on NCS 2.5.

My understanding from the product specification is that DAP protection is enabled until both UICR.APPROTECT is 0x5A and NRF_APPROTECT.DISABLE is 0x5A.

I modified the zephyr and nordic_hal to disable the code that alters the value of NRF_APPROTECT in systemInit().  

While my changes are working as expected, I have discovered that somehow the nrfjprog tool is able to overcome the DAP access protection.

After reset, I have UICR.APPROTECT == 0x5A   and NRF_APPROTECT.DISABLE = 0. At first after a reset the debug access port is disabled but then nrfjprog is able to overcome the protection and read memory and DAP is enabled.

>nrfutil device device-info
serial_number: 000504300626
        deviceFamily: NRF52_FAMILY
        deviceVersion: NRF52840_xxAA_REV3
        jlinkObFirmwareVersion: J-Link Ultra V4 compiled Sep 22 2022 15:00:10
        
C:\Users\antho>nrfutil device protection-get
serial_number: 000504300626
        core: Application
        access status: Debug access is currently disabled (status value: All)


>nrfjprog --memrd 0x40000000 --log
[error] [ Worker] - Access protection is enabled, can't read device version.
[error] [ Client] - Encountered error -90: Command read_device_info executed for 14 milliseconds with result -90
[error] [ Client] - Encountered error -90: Command read_memory_descriptors executed for 11 milliseconds with result -90
[error] [ Worker] - Can't read memory descriptors, ap-protection is enabled.
0x40000000: 00000000                              |....|

>nrfjprog --memrd 0x40000000 --log
0x40000000: 00000000                              |....|

>nrfjprog --memrd 0x40000558 --log
0x40000558: 0000005A                              |Z...|

>nrfjprog --memrd 0x10001208 --log
0x10001208: 0000005A                              |Z...|

>nrfutil device protection-get
serial_number: 000504300626
        core: Application
        access status: Debug access is enabled (status value: None)

According to the product specification (see attached diagram) the debug port should be "Closed"  until the firmware writes the APPROTECT.DISABLE with SwDisable (0x5A) .

How does nrfjprog manage to disable the access protection when the debug access port is disabled?

For additional detail. I noticed in the ozone debugger, I'm able to reset and halt and the NRF_APPROTECT->DISABLE has value 0x5A. 

 This environment does have mcuboot bootloader, is it possible the mcuboot is enabling access?

Is it possible to implement a mode on NRF52840 where the debug access port remains locked until enabled by firmware command?

Parents
  • +1

    Hi,

    I do not see how AP Protect could be disabled with the sequence you copy-pasted from the command line. nrfjprog can disable AP protect by performing a recover operation (erase all), but that is intentional and is not shown here. Do you do something else to the device int he meantime that is not shown there?

    I suspect that a bootlaoder may be part of this. As you write, you write the magic number 0x5A to diable AP protect to UICR->APPROTECT. So if any fortware component at any later time also writes to NRF_APPROTECT->DISABLE and there are no writes to NRF_APPROTECT->FORCEPROTECT, AP protect will be disabled.

    I would start by testing with the application and bootlaoder separately to see if only one is needed to open the debug interface, and then look closer there to see if you can find where NRF_APPROTECT->DISABLE is written to (if you for instance build the bootlaoder before and did not configure it to lock the debug interface, it will be opened by this line in system_nrf52_approcet.h as UICR->APPROTECT has the magic number even if you have modified it when you subsequently built the application.

Reply
  • +1

    Hi,

    I do not see how AP Protect could be disabled with the sequence you copy-pasted from the command line. nrfjprog can disable AP protect by performing a recover operation (erase all), but that is intentional and is not shown here. Do you do something else to the device int he meantime that is not shown there?

    I suspect that a bootlaoder may be part of this. As you write, you write the magic number 0x5A to diable AP protect to UICR->APPROTECT. So if any fortware component at any later time also writes to NRF_APPROTECT->DISABLE and there are no writes to NRF_APPROTECT->FORCEPROTECT, AP protect will be disabled.

    I would start by testing with the application and bootlaoder separately to see if only one is needed to open the debug interface, and then look closer there to see if you can find where NRF_APPROTECT->DISABLE is written to (if you for instance build the bootlaoder before and did not configure it to lock the debug interface, it will be opened by this line in system_nrf52_approcet.h as UICR->APPROTECT has the magic number even if you have modified it when you subsequently built the application.

Children
Related
Terms of service