Should the nrfjprog version 9.7.2 work with nRF52840_XXAA

[Pertti Kasanen]

I have a single sample of the new nRF52840_XXAA at hand on our custom board. I'm trying to do a --recover with nrfjprog. As the log below shows, nrfjprog recognizes it as NRF52832_XXAA and fails. Am I using a wrong version as the documentation says the version adds support for nRF52840_XXAA_ENGB? 

--------------------------------------------------------------------------------

/Users/perttikasanen/Downloads/nRF5x-Command-Line-Tools_9_7_2_OSX/nrfjprog/nrfjprog --recover --family nRF52 --log

nrfjprog verion 9.7.2

--------------------------------------------------------------------------------

FUNCTION: open_dll.

FUNCTION: open_dll.

FUNCTION: enum_emu_snr.

FUNCTION: enum_emu_snr.

FUNCTION: enum_emu_snr.

FUNCTION: enum_emu_snr.

FUNCTION: connect_to_emu_with_snr.

FUNCTION: connect_to_emu_with_snr.

FUNCTION: connect_to_emu_without_snr.

FUNCTION: enum_emu_snr.

Device "NRF52832_XXAA" selected.

FUNCTION: recover.

FUNCTION: recover.

JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.

JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.

FUNCTION: close_dll.

FUNCTION: close_dll.

log.log (END)

Segger SES does not manage it any better, "Connect J-Link" fails with:

Connecting ?J-Link? using ?USB?
Connecting to target using SWD
Loaded /Applications/SEGGER Embedded Studio for ARM 3.34a/bin/libjlinkarm.dylib
Firmware Version: J-Link Ultra V4 compiled Mar 29 2018 17:47:00
DLL Version: 6.30e
Hardware Version: V4.00
Target Voltage: 1.785
Device "NRF52840_XXAA" selected.
connect failed
Failed to connect to target.
No idcode detected.
Please check connection and Target Interface Type

Any hints?

Pertti

[Håkon Alseth]

Hi,

 

Your target voltage is just below 1.8V. It is not all programmers that support this voltage.

Which programmer are you using?

 

Best regards,

Håkon

[Pertti Kasanen]

Hi,

The programmer works fine with nRF52832 designs at (and a bit below) 1.8V. This was tested using a Segger J-Link Ultra+.

The prototype board worked with nRF52832. We are using Rigado modules here: It used to have a Rigado BMD-300 (with nRF52832) and that was replaced with a BMD-340 (with nRF52840). As seen in the log, the board has the intended ~1.8V operating voltage.

We are checking the connections, checking if something is keeping the nRF in reset etc. The main changes have been: connecting the SWO pin, connecting USB pins, VCCH and a few additional IO-pins

With this question I wanted to verify that should the (nrfjprog and SES) program versions I'm using work with the product version of nRF52840? And is there something wrong as the nrfjprog logs 'Device "NRF52832_XXAA" selected.' instead of nRF52840?

[Håkon Alseth]

Hi,

 

nrfjprog and supported IDEs, like SES, will work with the production version of nRF52840.

The recover and erase procedure is equal on the nRF52832 and the nRF52840, so the "device selected" in the log shall not make any difference.

 

Have you been able to program this device at one time, and it stopped working, or have you never been able to program it properly?

Is "JLink Commander" (JLinkExe in *nix based OSes) able to detect the device?

 

Best regards,

Håkon

[Pertti Kasanen]

No, we have not managed to connect or program it at all. 

nRF52840 consumes about 15 mW so it seems to be running? JLinkExe flashes red and orange leds when trying to connect. Next step will be connecting a logic analyses to the SWD pins and checking if we could learn something from that.

[Håkon Alseth]

Hi,

 

15 mW is 5 mA at 3V, which sounds reasonable if the CPU is running.

Are you sure this is not a soldering issue? Are you certain that you have connected to the correct pins on the module, and that there's no microscopic shorts between the two lines?

 

Best regards,

Håkon

[Pertti Kasanen]

Eventually we got this working. Building a manually soldered prototype of this required some tricks, we used castellated holes etc. First there must have been some other problem as this was originally tested - but at the end here was a hidden connection pulling the SWDCLK to the ground. Programming the nRF now works well.

[mnjLC]

I am currently using nrfjprog version 9.4.0 to program my project with BMD-340 (nrf52840) module. nrfjprog keeps detecting the nrf52840 as NRF52832_XXAA. Everything work fine and I am hesitant to change anything that is working. Can you comment on whether I should update my nrfjprog package on linux?

______________________________________________________________________

--------------------------------------------------------------------------------
.nrfjprog --log -f nrf52 --memrd 0x10001080 --n 8
nrfjprog verion 9.4.0
--------------------------------------------------------------------------------
FUNCTION: open_dll.
FUNCTION: open_dll.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_without_snr.
FUNCTION: enum_emu_snr.
Device "NRF52832_XXAA" selected.
FUNCTION: read_device_version.
FUNCTION: read_device_version.
InitTarget() start
InitTarget() end
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
[0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
[0][1]: E0001000 CID B105E00D PID 003BB002 DWT
[0][2]: E0002000 CID B105E00D PID 002BB003 FPB
[0][3]: E0000000 CID B105E00D PID 003BB001 ITM
[0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU
[0][5]: E0041000 CID B105900D PID 000BB925 ETM
FUNCTION: read.
FUNCTION: read.
FUNCTION: close_dll.
FUNCTION: close_dll.

______________________________________________________________________

Thanks!