NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Achim Kraus — Sun, 30 Apr 2023 15:15:36 GMT

After testing a while with my nRF5340-DK and the nRF Connect Programmer, my feeling is, the DK is bricked, because the target nRF5340 is "bricked". The Programmer tries to check, if it recognizes a valid Nordic device via JLink. If I switch the DK off and connect a nordic device to the external debug output of the nRF5340-DK, the nRF Connect Programmer detects both.

My conclusion: the onboard nRF5340 is somehow in a state, where Jlink can't read the device info.

I tried to understand the other comments, but I miss the sequence to unclock the nRF5340.

What I tried:

> nrfjprog -v

nrfjprog version: 10.15.1 external
JLinkARM.dll version: 7.80c

> nrfjprog -e --log

ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".

> nrfjprog --recover --log
ERROR: [SeggerBackend] - JLinkARM.dll reported "-1", "An unknown error.".

Edit:

Oh, what a mess! What a ridiculous waste of time!

It depends on using a debug header (TC2030-CTX). With that, the DK switches to the external debug interface and if on start no nordic device is connected to that external debug interface, the nRF5340-DK is refused by the programmer.

The nRF9160-DK doesn't show that effect. That works with and without that debug header.

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Dave H — Thu, 27 Apr 2023 10:40:11 GMT

Thank you, the CTRL-AP chapter linked above was very insightful. Much appreciated.

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Einar Thorsrud — Thu, 27 Apr 2023 07:35:47 GMT

Hi,

You are right that the information is a bit fragmented at the moment, but we are actively working to improve the the security related documentation. The Access port protection feature is documented in the CTRL-AP chapter in the product specification. The special thing about this feature is that it is enabled by default, but we try to hide these complexities with our tools. That is for instance why a "nrfjprog --recover" operation or similar writes to flash to open the debug port. Similarly, the default behavior when you build an application in the nRF Connect SDK is to include the code that open up the debug port by default (see Enabling access port protection mechanism for more details).

Regarding security related documentation in general, we have a high level starting point here: Security. There is also a separate chapter on security in the nRF Connect SDK.

Generally we try to avoid forcing you to use security features, but there are some features that are on by default or enforced by HW because that is required in order to provide the necessary level of security for those who needs it.

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Dave H — Wed, 26 Apr 2023 14:30:32 GMT

[quote userid="7377" url="~/f/nordic-q-a/99105/nrf-connect-programmer-v3-0-8-for-nrf5340-dk-not-working-on-linux/422555"]I see. But does programming work after you see this? I got this in the log as well once when I tested, but still programming/erase worked as expected.[/quote]

I confirm that programming/erase is working as expected in Linux. Even when it says "Device is protected"

[quote userid="7377" url="~/f/nordic-q-a/99105/nrf-connect-programmer-v3-0-8-for-nrf5340-dk-not-working-on-linux/422555"]It is not a bootloader, but when you use nrfjprog recover it will program a small snippet to page 0 that writes to APPROTECT.DISABLE to make it possible to debug or program the device subsequently. It also writes to UICR.APPROTECT, as both are needed to keep the debug interface open.[/quote]

Thanks, that is very useful. I will continue investigating along that line. I wish there was some article I could read that tells you what to do if you are not interested in any form of secure mode on this chip. The documentation is spread out and it seems like you need to know quite a lot about how security is implemented just to turn it off. I'm not saying that security is unimportant, just that it is not required in many instances.

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Einar Thorsrud — Wed, 26 Apr 2023 14:03:19 GMT

Hi,

[quote user="Dave H"]This happens regardless of whether or not I attempt to program a hex file or not. [/quote]

I see. But does programming work after you see this? I got this in the log as well once when I tested, but still programming/erase worked as expected.

[quote user="Dave H"]And I have found this issue to be intermittent too. Sometimes it works, sometimes not.[/quote]

Yes, that is interesting and I see the same (have only been able to reproduce once so far).

[quote user="Dave H"]On another note I have found that "nrfjprog --recover" works on Linux and is equivalent to "nrfjprog --recover --coprocessor CP_APPLICATION".[/quote]

Yes, those are equivalent. (And To recover the network core specify CP_NETWORK instead).

[quote user="Dave H"]I see that it writes some code to the 0x0 app core flash area. Does this have something to do with it being a boot loader and unlocking the peripherals? [/quote]

It is not a bootloader, but when you use nrfjprog recover it will program a small snippet to page 0 that writes to APPROTECT.DISABLE to make it possible to debug or program the device subsequently. It also writes to UICR.APPROTECT, as both are needed to keep the debug interface open.

[quote user="Dave H"]Can I do without such a thing and run the app core in secure mode in my application itself.[/quote]

This is overwritten when you subsequently program the device (typically with sectorerase) so after you program it with your own code there are no remains of this code snippet (other than in the UICR). The reason this is done is because APPROTECT is enabled by default and only disabled by an ERASEALL operation via the CTRL-AP or if disabled by firmware.

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Dave H — Wed, 26 Apr 2023 13:41:54 GMT

Hi,

This happens regardless of whether or not I attempt to program a hex file or not. And I have found this issue to be intermittent too. Sometimes it works, sometimes not.

To reproduce open nRF Connect Programmer 3.0.8 on Linux and click "Erase all". Most of the time I get "Device is protected". If I then eject the device and reconnect sometimes I get "Device is protected" and sometimes it works with "Device is connected". This seems to me like some sort of timeout that is incorrectly categorized as ap protect.

On another note I have found that "nrfjprog --recover" works on Linux and is equivalent to "nrfjprog --recover --coprocessor CP_APPLICATION". I see that it writes some code to the 0x0 app core flash area. Does this have something to do with it being a boot loader and unlocking the peripherals? Can I do without such a thing and run the app core in secure mode in my application itself. Bootloaders don't play nicely with the debugger I'm using.

RE: NRF Connect Programmer v3.0.8 for nrf5340 DK not working on Linux

Einar Thorsrud — Wed, 26 Apr 2023 12:46:21 GMT

Hi,

Did you try to program a hex file? I ask because I see the same error in the log on my end when opening v3.0.8 on Ubuntu 22.04 LTS, but both erase and write works as expected.