nrf52840 DK HW rev 3.0.1

RE: nrf52840 DK HW rev 3.0.1

Amanda Hsieh — Wed, 24 May 2023 15:16:28 GMT

Hi,

According to https://infocenter.nordicsemi.com/pdf/in_151_v1.0.1.pdf?cp=18_6, it is required to upgrade to the latest MDK (version 8.43.0 or later) to support APPROTECT.

Regards,
Amanda H.

RE: nrf52840 DK HW rev 3.0.1

RichardHdrd — Wed, 24 May 2023 10:07:52 GMT

Hi Amanda,

thank you very much for all the support. Now, following the post you linked, I was able to compile my code for the nrf52840 DK as well as BM833.

But I also use a BM833A which is a nRF52811 chipset. There, I still cannot compile using the additional code.

Now checking the definition for e.g. "UICR_APPROTECT_PALL_HwDisabled" in the new MDK (shipped with SDK 17.1.0) renders, that it is found in the following files:

./modules/nrfx/mdk/nrf52833_bitfields.h
./modules/nrfx/mdk/nrf52820_bitfields.h
./modules/nrfx/mdk/nrf52840_bitfields.h
./modules/nrfx/mdk/nrf52_bitfields.h

The also (in this folder) contained file nrf52811_bitfields.h doesn't contain the required definitions.

Again, I'd like to know if there is a solution to that, because generally 52811 seems to support APPROTECT:

https://infocenter.nordicsemi.com/pdf/nRF52811_PS_v1.0.pdf

Best regards,

Richard

RE: nrf52840 DK HW rev 3.0.1

Amanda Hsieh — Mon, 22 May 2023 20:46:47 GMT

Hi,

See this post.

-Amanda H.

RE: nrf52840 DK HW rev 3.0.1

RichardHdrd — Mon, 22 May 2023 11:58:30 GMT

Hi Amanda,

I followed the steps concerning:

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.

This allows the code to be accessed while the DK stays connected. But as soon as Idisconnect & reconnect the DK, the APPROTECT is reported to be enabled again.

Performing the above steps without " ERASEALL operation:" doesn't allow to re-disable APPROTECT.

So it seems that the uploaded code/Softdevice enable the APPROTECT by default.

So I went to the example describing on how to set the APPROTECT withing the App (see Step 2: Setting UICR.APPROTECT):

I tried adding the code to the main of my project. As stated, I use Segger Embedded Studio: 5.4.4

I got a complaint from the compiler:

‘UICR_APPROTECT_PALL_HwDisabled’ undeclared (first use in this function); did you mean ‘UICR_APPROTECT_PALL_Disabled’?

Now I read in the related post, which I assume is source of the trouble:

NOTE: If using the nRF5 SDK then ensure that it has been updated to MDK version 8.45.0 or newer.

I'm using SDK 17.0.2. I could not determine the MDK version used, but checking for MDK, I found out, that this is some KEIL related stuff, which I'm not using since I use Segger Embedded Studio.

How can I create that APPROTECT-setting code using Segger Embedded Studio?

Best regards,

Richard

RE: nrf52840 DK HW rev 3.0.1

Amanda Hsieh — Mon, 15 May 2023 16:17:50 GMT

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.

RE: nrf52840 DK HW rev 3.0.1

RichardHdrd — Mon, 15 May 2023 09:34:58 GMT

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

RE: nrf52840 DK HW rev 3.0.1

Amanda Hsieh — Thu, 11 May 2023 14:35:37 GMT

Hi,

[quote user="RichardHdrd"]Is there a command to persistently create the effect of "nrfjprog --recover"?[/quote]

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

[quote user="RichardHdrd"]What must be considered to get this running again?[/quote]

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.

RE: nrf52840 DK HW rev 3.0.1

RichardHdrd — Thu, 11 May 2023 09:10:58 GMT

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

RE: nrf52840 DK HW rev 3.0.1

Amanda Hsieh — Mon, 08 May 2023 17:35:51 GMT

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.