NOT_AVAILABLE_BECAUSE_PROTECTION, jlink fails, nRF Connect for desktop fails

[brec]

I keep seeing NOT_AVAILABLE_BECAUSE_PROTECTION errors on all sub-programs of nRF Connect when attempting to program the associated firmware (RSSI viewer, Bluetooth Low Energy, Programmer, etc). J-Link command line keeps flagging the part as protected every time I connect to it:

nrfjprog gives:

C:\windows\system32>nrfjprog --family nrf52 --recover
Recovering device. This operation might take 30s.
ERROR: Recover failed. Please make sure that the correct device family is given
ERROR: and try again.

C:\windows\system32>nrfjprog -v
nrfjprog version: 10.12.1
JLinkARM.dll version: 6.90

I can only program the part through dropping a hex file on the JLINK drive or through nRF Connect SDK version of SES.

Part = nRF52840

nRF Connect for Desktop v3.6.1

How can I use any of the nRF Connect for Desktop apps?

Thanks,

Bob

[Simonr]

Glad you were able to (at least partly) solve this on your end. However, what you're explaining seems very weird, and I'll contact our desktop developer team to see if they know what is going on here. Thank you for your thorough research and explanation of the matter! I will get back to you as soon as I hear back from the devs.

What hardware version(s) are these nRF52 Development Kits that run into these nRFConnect for Desktop "Protection" errors, and are they all nRF52832 DKs, or do you have some nRF52840 kits as well? Can you provide the log file of the nRFConnect BLE app you're seeing?

Best regards,

Simon

[brec]

Hi Simon,

I'm actually running four of our own BMD-380-EVAL EVKs, one at a time. All do the same thing.

They're functionally equivalent to your nRF52840 DK, right down to the Atmel part running the J-Link-OB interface. On the EVKs are our BMD-380 modules with Rev 2 silicon of the nRF52840-CKAA.

Here's a recovery of one of the boards with the older nrfjprog:

H:\>nrfjprog --version
nrfjprog version: 10.10.0
JLinkARM.dll version: 6.84a

H:\>nrfjprog --family nrf52 --recover
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.

H:\>

Right after executing the above, I tried the latest nRF Connect. Upon selecting the EVK, I see a dialog box indicating that the firmware needs loaded. I click "Yes". After about 10 seconds, I see the protection error. Here's the log:

Fullscreen 2021-01-05T22_04_45.985Z-log.txt Download

2021-01-05T22:04:46.438Z INFO Application data folder: C:\Users\brec\AppData\Roaming\nrfconnect\pc-nrfconnect-ble
2021-01-05T22:04:46.553Z DEBUG App pc-nrfconnect-ble v2.4.2 official
2021-01-05T22:04:46.553Z DEBUG App path: C:\Users\brec\.nrfconnect-apps\node_modules\pc-nrfconnect-ble
2021-01-05T22:04:46.553Z DEBUG nRFConnect 3.6.1 is supported by the app (^3.6.0)
2021-01-05T22:04:46.553Z DEBUG nRFConnect path: C:\Users\brec\AppData\Local\Programs\nrfconnect\resources\app.asar
2021-01-05T22:04:46.553Z DEBUG HomeDir: C:\Users\brec
2021-01-05T22:04:46.554Z DEBUG TmpDir: C:\Users\brec\AppData\Local\Temp
2021-01-05T22:04:47.451Z VERBOSE Could not fetch serial number for serial port at COM3
2021-01-05T22:05:01.141Z ERROR Failed to setup device: Error occured when close opened device. Errorcode: CouldNotResetDevice (0x5)
Lowlevel error: NOT_AVAILABLE_BECAUSE_PROTECTION (ffffffa6)

FYI, COM3 is internal to the laptop.This EVK is on COM19.

I have an nRF52840 DK (PCA10040) v1.0.0 as well. I have not tried anything on it yet, but will and enter an update here.

Cheers,

Bob

[Simonr]

Hi

Okay, the fact that you use the BMD-380-EVAL EVKs at least explain why you have issues with the nRFConnect BLE app, because the Segger IDs for these devices doesn't match our DK IDs, so nRFConnect won't know what sort of device you're trying to connect to. The reason it is like this specifically for the BLE app is that the BLE app requires the connected device to work with any BLE device, which is why the app is locked to a specific range of Segger IDs. AFAIK, there are no plans to change this.

However this shouldn't affect nrfjprog, and the error messages you're seeing doesn't reflect this. Please confirm that you don't see these errors on the other nRFConnect apps, as these shouldn't be restricted to our DKs.

Please also note that the PCA10040 is the nRF52832 DK, while the nRF52840DK is called PCA10056. Please confirm which of these DKs you have, and whether it is working as intended. We don't have too much experience with the BMD-380 EVKs, so you could also ask U-Blox if they have seen anything like this on their end.

Best regards,

Simon

[brec]

Hi Simon,

I am the u-blox guy and trying to figure out why operation changed. This is the first we've seen the issue.

I can run the nRF Connect BLE and Programmer app on a BMD-340-EVAL (nRF52840-QIAA) that I have at my desk. The only differences between these two EVKs is the routing for the different size module. All of the SEGGER-side circuitry is the same. I can also run it on the BMD-300-EVAL (nRF52832-QFAA) -- I've been doing this for some time on various of our EVKs. nrfjprog runs as expected as well on all of them.

All I can think of is that I was also running the nRF Connect SDK tools on these same BMD-380-EVAL boards right at the time v1.4.99-dev1 showed up in the Toolchain Manager -- trying the peripheral_lbs, peripheral_uart, and central_uart examples. Did something change in those programming commands in the new SDK? Where can I find the programming scripts?

I'll get a fresh BMD-380-EVAL and try it later today. Perhaps it was operator error when I was working with the four boards in question.

The nRF52840 DK I used yesterday is indeed the PCA10056, v1.0.0. I can also run it on several nRF52 DKs, PCA10040.

Cheers,

Bob

[brec]

Hi Simon,

Fresh boards operate the same, so that eliminates any issues with the nRF Connect SDK and tools.

The only board I'm having trouble with is the BMD-380-EVAL. Our BMD-340-EVAL, BMD-341-EVAL, and BMD-345-EVAL can all be erased with nrfjprog -f nrf52 --recover (tools v10.12.1 / J-Link v6.88a). All of them use the nRF52840. The only difference is that the BMD-380 uses the CKAA package, where the others use the QIAA. I checked the EVAL schematics. They're identical except for a couple GPIOs that weren't mapped to module pins on the BMD-380.

Do you have any boards there with the CKAA package to try?

Cheers,

Bob