Flashing failed due to protection on the device

[Bryan]

OS: Windows 10
NCS: 2.0.0

I am working on the Nordic DFU NCS Guide on a nRF52833 DK  devzone.nordicsemi.com/.../ncs-dfu

After flashing/debugging several times, I started seeing the message below.  I responded with "yes".   Now I am not able to "debug".  I can only "flash" it. 

I thought something was wrong with the board, so I used a brand new nRF52833DK.  The same thing started happening.  

Any idea of what is going on?

[dejans]

Hi,

I have reproduced your issue by erasing the board and power cycling it, but as soon as the board was recovered the issue disappeared.
After you recover the board with

nrfjprog --recover

or from VS Code, APPRPOTECT should be disabled. Normally, it should stay in disabled state unless your application enables it. You can check which APPROTECT options you have enabled in your application by looking at .config file in your build\zephyr folder. You can find more information about APPROTECT in the documentation. 


Best regards,
Dejan

[Bryan]

dejans,

Thank you for the response.  Yes, I had already tried "nrfjprog --recover".  That did not resolve the issue.

I went through your recommendations, the only APPRPOTECT in build\Zephyr\.config are:

CONFIG_NRF_APPROTECT_USE_UICR=y
# CONFIG_NRF_APPROTECT_LOCK is not set

I added the below to prj.conf, but .config stayed the same.

CONFIG_NRF_APPROTECT_USE_UICR=n

Even if I run "nrfjprog --recover" and try to program a completely different application (BLE app), I get the same error.  You can see in the terminal the --recover option is run when I "flash", followed by a power cycle, and then try to "debug".

[Bryan]

One other piece of information.  If I switch to any other project, I am still getting the same warning and I am unable to "debug", but can "flash".

[dejans]

Hi,

You could try recovering in a separate nrfjprog command, before flashing.

Best regards,
Dejan

[Bryan]

I did that, too.  
1. nrfjprog --recover
2.  Try to "debug".  It downloads without error, but when I click "go", it does nothing.

This is just bizarre.  There is obviously some low level or tool issue.  I can't waste time trying to figure it out.  I will have to live with flashing and no debug.

[dejans]

Hi,

In order to avoid black window in your initial screenshot from showing up again, you can either choose "Yes" or "Always in this session" which should enable flashing with recovering. Then, this black window should disappear. Another option would be to create custom flash task where you could specify how you want flashing to be performed. Having said that, readback protection might be re-enabled if you build and flash application which enables it.

Best regards,
Dejan

[Bryan]

I am re-opening this ticket.  I believe there is something wrong with the nRF52833DK or the interaction with NCS.  I have upgraded to NCS 2.2.0.  I now have four nrf52833DK boards that are acting this way.  In addition, I know another developer that is seeing the same issue.  I have tested on the nRF52832DK and nRF52840DK, too.  These boards don't show the same behavior at this time.

dejans said:

In order to avoid black window in your initial screenshot from showing up again, you can either choose "Yes" or "Always in this session" which should enable flashing with recovering. Then, this black window should disappear. Another option would be to create custom flash task where you could specify how you want flashing to be performed. Having said that, readback protection might be re-enabled if you build and flash application which enables it.

There is a fundamental problem with this comment that I maybe wasn't clear about.  Once the board gets into this state, I can never run in debug mode again which is obviously fundamental functionality for embedded development.  However, I can still flash the devices and they execute code.

Here is a complete overview of what I am seeing...

The boards work perfectly out of the box.  I can debug or flash several different examples without error.

However, I am working on DFU over BLE and that is where the issues appear to begin.  I have attached the simple Hello World BLE DFU example for reference.

0143.hello_world_dfu.zip

1.  The project build configuration has "Enable Debug Options" enabled.

2. Attempt to debug in VS Code.  



3. If I run "nrfjprog -f nrf52 --recover followed by "nrfjprog -f nrf52 --eraseall from the command line and then attempt to start "debug" and it shows the debug window (circled), but a single step generates an error (arrow).  Nothing is executed.

[dejans]

Hi,

I have tried to reproduce your issue without success. Upon pressing  Debug I got error "Unable to read registers" and debug ended up in cortex_m -> fault_s.S. I have used NCS v2.2.0 and nRF52833-DK board v1.1.0. The error is shown below.



I do not see from your video that you set a break point somewhere in the code.

Which board version did you use?

Best regards,
Dejan

[Bryan]

Dejan,

It doesn't always happen the first time.  It appears to be very random, but once it happens I can not debug.I have two boards on my desk with the failure (other boards are at home).

dejans said:

I do not see from your video that you set a break point somewhere in the code.

I can not set a breakpoint, single step, or do any sort of debug.

Board 1

1.1.0

2022.15

Board 2

1.1.0

2022.5

[dejans]

Hi,

I have tested with another nRF52-DK v1.1.0 board. I could not reproduce your error, but managed to reproduce what I saw using my other nRF52-DK. 

Best regards,
Dejan