Hi!
First of all, sorry but I will not be able to provide anything to re-create the bug... I did modify the code that may have made it happen in the first place quite a lot before noticing the issue, and can't tell exactly during which step it happened.
I am using the 17.1.0 SDK and S140 Softdevice, on a NRF52840 DK, with a NRF52 dongle connected by SWD to the DK
The project is a pretty simple custom BLE service with a few characteristics to exchange data streams. The feature I was trying to implement was writing the new name of the BLE peripheral in the flash if its name characteristic is written, such as to keep the new name for future advertising. To that end, I initially tried to access the flash at register level, which messed with the Softdevice. I then tried it using the Flash Data Storage library, and finally the sd_flash_write function (to be exact I tried multiple implementation of the last two over a few iterations).
As it finally appeared to have been working, the CTRL-AP bit locking the code enabled itself. I cleared it with OpenOCD and telnet using nrf52_recover, which worked fine, but the lock re-enables itself after power cycling, but not after resetting.
This behavior persists when flashing code known to work, like the SDK blinky, which still gets locked after power cycling.
It also seems to... propagate? As I plugged a new unopened dongle which directly claimed to have the CTRL-AP enabled. I then plugged a new JLink (however no new targets left) which yielded the same result. I also reinstalled the JLink drivers and tried both the JLink software and OpenOCD which both have the issue.
Does anyone have an idea on what could be happening? The more things I try, the stranger it seems.
