nrf52840 DK HW rev 3.0.1

[RichardHdrd]

Dear Forum,

We obtained a nrf52840DK in HW rev. 2.0.1 some time ago. This HW-revision worked in every aspect as expected, which means:

1) It could be adressed;

read deviceversion:

>>nrfjprog --deviceversion
NRF52840_xxAA_REV2

read MAC:

>>nrfjprog --memrd 0x100000A4 --n 8

[MACBYTES]

2) It's memory could be read out with the nordic programmer:

Select Device-->(read button enabled)

Code compiled for pci10056 could be uploaded and run on the DK.

4) Segger Embedded Studio's debugger could run code on BM833 devices connected via PINs VTG, SWD IO, SWD CLK and GND DETECT as well as on the DK. This fails, the PINs no longer are available and the DK is not detected by the debugger.

Now we needed further DKs and reordered them, they came as nrf52840DK in HW rev. 3.0.1, they operate on a 5340 chip, as can be seen on the PCB.

This revision failed to worked in every aspect as expected, which means:

1) It cannot be adressed;

read deviceversion:

>>nrfjprog --deviceversion
ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

read MAC:

>>nrfjprog --memrd 0x100000A4 --n 8

ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.

2) It's memory could be read out with the nordic programmer:

Select Device-->(read button disabled)

Code compiled for pci10056 could be uploaded and run.

After forcedly clearing the device, code compiled for pci10056 can be be uploaded, but will not run.

After each unplug/replug, the forced clearing has to be done again, else the state will be as described above for rev. 3.0.1

3) Segger Embedded Studio's debugger running code: This fails, the named PINs no longer are available and the DK is generally not detected by the debugger, even standalone.

Question: How must the rev. 3.0.1 DK be prepared and adressed to behave as a nrf52840 DK rev. 2.0.1?

***********************************************************************************************************************

Additional Info:

Using Ubuntu Linux,  20.04.6 LTS

nrfjprog --version
nrfjprog version: 10.12.1
JLinkARM.dll version: 6.88a

nrfConnect for Desktop: 3.11.0

Programmer: 2.3.3

Segger Embedded Studio: 5.4.4

Best regards,

Richard

[Amanda Hsieh]

Hi, 

As the log indicated, please use "nrfjprog --recover" to unlock the device. Since nRF52840DK v3 use nRF52840 (revision 3, build codes Fx0) include an improved implementation of the the access port protection mechanism. It needs to unlock the device before programming/accessing the device. See more information in this blog Working with the nRF52 Series' improved APPROTECT .

Regards,
Amanda H. 

[RichardHdrd]

Hi Amanda,

Thank you for hint, wich solves some of my problems. But it seems, every time I want to reprogram the device, it requires to perform the "nrfjprog --recover" again before the device becomes re-accessible again?

Is there a command to persistently create the effect of "nrfjprog --recover"?

Further:

The old device (2.0.1), when connected to a linux PC showed one tty: ttyACMx

The new one (3.0.1) shows two ttys: ttyACMx AND ttyACMx+1

Now, when interfacing with e.g. UART, which of the ttys is generally to be used, what's the other tty's purpose?

Additionally, I did scan for devices with nordic sniffer using the DK:

[Program DK]:

/usr/bin/sudo /usr/bin/nrfjprog --family NRF52 --chiperase --program /home/richard/Downloads/sniffer/hex/sniffer_nrf52840dk_nrf52840_4.1.1.hex -r --verify

[Sniff]:

/usr/bin/sudo -u richard /usr/local/bin/nrf-sniffer-cli scan

This worked and still works with the old DK (2.0.1) but generally fails on new DK (3.0.1), as it reports: "no sniffers found!".

What must be considered to get this running again?

Best regards,

Richard

[Amanda Hsieh]

Hi,

RichardHdrd said:

Is there a command to persistently create the effect of "nrfjprog --recover"?

See the Step 2: Setting UICR.APPROTECT section in this blog Working with the nRF52 Series' improved APPROTECT.

RichardHdrd said:

What must be considered to get this running again?

The issue affects the UART connection on v3.0.0. Since the nrf52840 DK has a USB port the workaround is to use the second USB connection instead (or in addition if you want to use 2 USB cables).

Using the second USB port on the DKs that have them is the recommended setup. The USB is more reliable and faster.

The following is my test, and I can see the nRF52840DK v3.0.0 sniffer interface.

-Amanda H.

[RichardHdrd]

Hello Amanda,

Thank you again, using the extra USB Port solved the sniffer issue.

Only to get everything right, referring to Step 2: Setting UICR.APPROTECT section in this blog Working with the nRF52 Series' improved APPROTECT.t:

The basic way to disable is init-sequence:

nrfjprog --recover

<initial-program some hex>

nrfjprog --memwr 0x10001208 --val 0x00

This seems to allow reprogramming after the initial-program:

<re-program some hex>

nrfjprog --memwr 0x10001208 --val 0x00

But after unplugging the device, the init-sequence has to be repeated, as I observed.

Now for the lower part (register access):

Quote:

>>

J-Link>SWDSelect

(...)

The APPROTECTSTATUS register can be read without selecting a different AP:

SWDReadAP 3
    Read AP register 3 = 0x00000001

A value of 1 means that access port protection is disabled.

<<

Now, would the following command (instead of SWDReadAP 3) allow to set the value permanently to "1":

SWDWriteAP 3 0x00000001

So basicallywould that permanently disable UICR.APPROTECT until it is intentionally enabled again?

If not that way, how can that state be reached?

Best regards,

Richard

[Amanda Hsieh]

Hi, 

Once UICR.APPROTECT APPROTECT  is set to disable, it will disable the approtect feature until the UICR.APPROTECT is set to enable and perform any reset. See Access port protection documentation. 

-Amanda H.