Does enabling APPROTECT block DFU (BLE update via MCUboot)?

Hi,

I’m working with an nRF52840 that supports Bluetooth Low Energy updates via MCUboot.

We want to enable APPROTECT on our production units to prevent competitors from attaching a debugger.
To do this, we run the following command:

nrfjprog --memwr 0x10001208 --val 0x00000000

with 0x10001208 being APPROTECT (access port protect)


This works as expected — once executed, the unit cannot be debugged and must be fully erased before reflashing.
So far, so good.

The issue

After enabling APPROTECT, DFU over BLE no longer works.

  • Expected behavior (without APPROTECT):
    Using the nRF Connect Device Manager (DFU) app, the update proceeds normally (takes a few minutes).
    The device restarts afterward and shows the new firmware version.

  • Observed behavior (with APPROTECT enabled):
    The update starts and almost immediately completes, reporting “Success”.
    However, the device does not restart, and after a manual reboot, it still runs the old firmware.

Question:

Is this intended behavior when APPROTECT is enabled?
Or should DFU updates via BLE and MCUboot still be possible even with APPROTECT active?

our updating logic is as follows:

Parents
  • Hi Wouter,

    I don't see a reason why enable APPROTECT would cause problem with DFU. 
    When you observed that "The update starts and almost immediately completes, reporting “Success”." did you full erase the chip before flashing the application before DFU ? What can happen is that if the image is already on the secondary slot, it will not be transmitted again. 

    Could you try to reproduce the issue on a simple smp server sample ? Please check if you can find any log from MCUBoot. 
    Which SDK version you are on  ? 

Reply
  • Hi Wouter,

    I don't see a reason why enable APPROTECT would cause problem with DFU. 
    When you observed that "The update starts and almost immediately completes, reporting “Success”." did you full erase the chip before flashing the application before DFU ? What can happen is that if the image is already on the secondary slot, it will not be transmitted again. 

    Could you try to reproduce the issue on a simple smp server sample ? Please check if you can find any log from MCUBoot. 
    Which SDK version you are on  ? 

Children
  • Hi Hung,

    thanks for your time.

    I’m using nRF Connect SDK version 2.7.0.

    At this point, I’m unable to reproduce the issue, either on a minimal setup or on our original configuration where it was first observed.

    While it’s a bit concerning that the problem has disappeared, there’s not much I can do without being able to reproduce it.
    For now, I’ll consider this issue closed, unless it reappears in the future.

    Best regards,
    Wouter

Related