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]

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