Unresponsive nRF9160 Thing Plus

Development Boards Other Microcontrollers
1

I got a nRF9160 a few days ago and would initially go into DFU mode with the blue LED on but I think I corrupted MCUBOOT and I can’t get it to respond to anything anymore. I understand that I need the programmer cable to access it without MCUBOOT but that isn’t working. How do I know if my board went bad or if there is something else I’m doing wrong. When I plug in the USB the right LED lights up for <1 second and then all LEDs go dark.

I have a Thingy:91 that programs fine with the exact same setup.

C:\Users\john>nrfjprog -v

nrfjprog version: 10.19.0 external

JLinkARM.dll version: 7.88j

C:\Users\john>nrfjprog --ids --expand

---------- Emulators ----------

serial number: 960087317

connection type: USB

C:\Users\john>nrfjprog -f NRF91 --pinreset

Applying pin reset.

C:\Users\john>nrfjprog -r

Applying system reset.

Run.

C:\Users\john> nrfjprog --recover --log

Recovering device. This operation might take 30s.

Erasing user code and UICR flash areas.

Unplugging the debug cable from the Thingy:91 and plugging in the nRF9160 Thing Plus I get these failures

nrfjprog --deviceversion

960087317 - NRF9160_xxAA_REV2

[error] [SeggerBackend] - Cannot call is_connected_to_device when connect_to_emu_without_snr or connect_to_emu_with_snr has not been called.

C:\Users\john>nrfjprog -f NRF91 --pinreset

Applying pin reset.

C:\Users\john>nrfjprog -r --log

[error] [SeggerBackend] - JLinkARM.dll reported “-1”, “An unknown error.”.

{29 times}

ERROR: Unable to connect to a debugger.

[error] [SeggerBackend] - JLinkARM.dll reported “-1”, “An unknown error.”.

{31 times}

ERROR: JLinkARM DLL reported an error. Try again. If error condition

ERROR: persists, run the same command again with argument --log, contact Nordic

ERROR: Semiconductor and provide the generated log.log file to them.

C:\Users\john>nrfjprog –recover

{same 60 errors as above}

C:\Users\john>nrfjprog --deviceversion

[error] [SeggerBackend] - JLinkARM.dll reported “-1”, “An unknown error.”.

…

960087317 - UNKNOWN

[error] [SeggerBackend] - JLinkARM.dll reported “-1”, “An unknown error.”.

Trying a Linux system different program versions gets similar results

Thingy:91 plugged in

jstuewe@Inspiron-3910:~$ nrfjprog -v

nrfjprog version: 10.21.0 external

JLinkARM.dll version: 7.88g

jstuewe@Inspiron-3910:~$ nrfjprog --ids --expand

---------- Emulators ----------

serial number: 960087317

connection type: USB

jstuewe@Inspiron-3910:~$ nrfjprog -f NRF91 --pinreset

Applying pin reset.

jstuewe@Inspiron-3910:~$ nrfjprog --deviceversion

960087317 - NRF9160_xxAA_REV2

jstuewe@Inspiron-3910:~$ nrfjprog -r --log

Applying system reset.

Run.

jstuewe@Inspiron-3910:~$ nrfjprog --recover --log

Recovering device. This operation might take 30s.

Erasing user code and UICR flash areas.

Switching out the Thingy:91 with the nRF9160 and I get the failures below

jstuewe@Inspiron-3910:~$ nrfjprog --deviceversion

[error] [ Client] - Encountered error -102: Command connect_to_emu_with_snr executed for 250 milliseconds with result -102

960087317 - UNKNOWN

[error] [ Worker] - An unknown error.

jstuewe@Inspiron-3910:~$ nrfjprog -r --log

[error] [ Client] - Encountered error -102: Command connect_to_emu_with_snr executed for 243 milliseconds with result -102

ERROR: Unable to connect to a debugger.

[error] [ Worker] - An unknown error.

ERROR: JLinkARM DLL reported an error. Try again. If error condition

ERROR: persists, run the same command again with argument --log, contact Nordic

ERROR: Semiconductor and provide the generated log.log file to them.

jstuewe@Inspiron-3910:~$ cp log.log log20230703.log

log file attached.

Any ideas what may be happening other than bad hardware

log20230703.zip (16.2 KB)

2

I’ve already tried two different cables and this cable\programmer combo works perfectly on the thingy:91. I’m using nrjfproj downloaded last week.

From windows: nrfjprog version: 10.19.0 external

From Ubuntu 22.04: nrfjprog version: 10.21.0 external

Any other ideas? Could I just have a bad board?

3

I bought a second nRF9160 Thing Plus and managed to do the exact same thing to it. It was working fine, I edited prj.conf in the blinky example and uploaded it with newtmgr and the example worked correctly reporting when I pushed the button. However, when I press the mode button the LED comes on BLUE, stays on blue while I press and release the reset button, and then all LEDs go off when I released the mode button. Now both of my Thing Plus’s won’t go into programming modes so I need to use the cable to recover them.

… but the debugger will NOT find the device and never has. Re-verified that if I unplug the nRF9160 Thing Plus and plug in my Thingy:91 prototype it immediately sees it and can program it so my debugger, cable, and software are all set up right.

If I go into J-Link v7.8.8k and Connect-> CORTEX-M33-> SWD → 9600 my Thingy:91 reports “Connecting to target via SWD Found SW-DP with ID 0x6BA02477”

Doing the same thing on BOTH of my nRF9160 thing Plus boards reports “Connecting to target via SWD Failed to attach to CPU. Trying connect under reset. Cannot connect to target.”

Any ideas here? These are both nRF9160 based boards so they should both respond to the debugger the same, right? Any ideas?

4

I finally found the issue!! The nRF9160 DK programmer defaults to 1.8v IO which matches the Thingy:91. The nRF9160 Thing Plus uses 3.3v I/O voltage so there wasn’t enough voltage to program it.

I was following the instructions at https://learn.sparkfun.com/tutorials/nr … okup-guide which don’t mention this at all. The solution is to change the position of SW9 from 1.8v to 3.3v as described in section 5.3.2 of the nRF9160 DK users guide.

There is no way for a beginner to know this is necessary though. Can someone update the hookup-guide to help others avoid the pain I’ve gone though please? I’ve spent 20-30 hours going back and forth on this issue.