This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

After a bootloader secured with NRF_BL_DEBUG_PORT_DISABLE is flashed, can it be re-flashed with a debug bootloader?

Hello,

I am using the nRF52840_DevKit and SDK-v16.0.0. I am planning to build and flash a bootloader with NRF_BL_DEBUG_PORT_DISABLE set to 1, which means APPROTECT and DEBUGCTRL fields in the UICR will be cleared (and thus the protection enabled).

After such a bootloader build is flashed, can I still do erase command over J-Link connection on the devKit or would an external J-Link device be needed?

If not, what settings should I use to protect against flash and ram read back, but still allows the device flash to be erased and thus re-initialized?

Thank you for everyone's time.

Parents Reply
  • Hi Vidar,

    Thanks for the response. Just making sure, with the protections enabled, the only option is to erase-all the flash and start again, correct? and this is a behaviour of the chip and not something that `nrfjprog` tool enforces.

    For my own education, is there a good reference that describes the various debug connections scope and usage? I am not clear on the difference between SWD, JTAG, DAP, and ITM/ETM traces, and RTT with context to the nRF52840.

    Thanks again!

Children
  • (for others following the thread) - There is a pretty good reference in the processor's Product Spec under `Core Components >> Debug and Trace`.

    @Vidar: Can you please confirm my understanding 

    APPROTECT when enabled, disables access to AHB-AP part of the DAP. However, because the CTRL-AP part of the DAP cannot be disabled, the CPU is still able to do CTRL-AP operations (which are limited to RESET, ERASEALL and checking the status of ERASEALL and APPROTECT).

    DEBUGCTRL (I think some documentation on this is useful in the "Debug and Trace" part of the doc)
    when enabled, can protect access by disabling two components:
    1. CPUNIDENThe ETM and ITM block of the CPU. This has to do with tracing and is a separate function than the DAP.
    2. CPUFPBEN: The CPU flash patch and breakpoint (FPB) capabilities.

    Thus, with both APPROTECT and DEBUGCTRL protections all set to enabled, one can disable debug and trace access, but still allow ERASEALL operation via CTRL-AP
     

  • Yes, I think you have understood it correctly. As you said, debug and trace access will be disabled when APPROTECT and DEBUGCTRL are enabled, but the ERASEALL operation will still be permitted through the CTRL-AP port.

Related