nRF52832 not connected anymore after first trying to debug (Keil)

[Manuel55]

Hi everyone,

I have a problem with my custom nRF52832 hardware. I soldered my prototype hardware and then I checked if it is correct by checking debugger SW device settings in Keil. It was listed there. Then I started a JLink debugging session and suddenly there was an error "No Cortex-M SW Device Found*. Since then, the SD device is not listed anymore. No way to bring it back…

So I removed the processor and replaced it by a new one. Exact same behavior.

A colleague at work had the same problem. He soldered a new hardware and then everything was fine. Before I re-solder my hardware too, I want to ask here if someone had the same problem once?

This is my hardware design:

 

Thank you very much for the help!

edit:

I'm also not able to connect over nrfjprog. I also tried with J-Link Commander V6.40 and this is the output:

SEGGER J-Link Commander V6.40 (Compiled Oct 26 2018 15:06:29)
DLL version V6.40, compiled Oct 26 2018 15:06:02

Connecting to J-Link via USB...O.K.
Firmware: J-Link EDU Mini V1 compiled Oct 26 2018 12:05:31
Hardware version: V1.00
S/N: 801005001
License(s): FlashBP, GDB
VTref=3.267V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: NRF52832_XXAA
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF52832_XXAA" selected.


Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
SWD speed too high. Reduced from 4000 kHz to 2025 kHz for stability
Found SW-DP with ID 0x2BA01477
Could not power-up debug power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Could not power-up debug power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use

****** Error: Could not find core in Coresight setup
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Could not power-up debug power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Could not power-up debug power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Cannot connect to target.
J-Link>

And this is the output from another PCB with the exact same hardware on it, only the MCU is a nRF52810 this time.

I also made some experiments with the board from my collegue. It is not programmable and after random retries to do so, it goes into the same state and is no longer available. After some time, it is available again...

[Håkon Alseth]

Hi,

 

Have you tried "nrfjprog --recover -f nrf52"?

If the firmware is asserting early in the process, you can enter a reset loop provided that blocking assertions is not enabled (define "DEBUG" set), which can be tricky to get out of.

Have you checked the power consumption of your device? You could also try to touch over the SWDCLK and SWDIO pin to see if there might be a marginal solder joint.

 

Kind regards,

Håkon

[Manuel55]

Hi Håkon,

Thank you for your answer!
Yes, I have tried "nrfjprog --recover -f nrf52". The output is:

nrfjprog -f nrf52 --readregs
ERROR: Cannot connect to any nRF device. Please make sure a device is
ERROR: connected to the debugger and supplied.

Håkon Alseth said:

If the firmware is asserting early in the process, you can enter a reset loop provided that blocking assertions is not enabled (define "DEBUG" set), which can be tricky to get out of.

Can you explain this a little bit better. I can't understand exactly what this means... I have an LED on a GPIO (13) and it is blinking so it seems like a reset loop issue.

The power consumption in below 1mA which is not normal. With a functional hardware it's about 5mA with the debugger connected. I will check those two pins for strange behaviour.

Best regards,

Manuel

[Håkon Alseth]

This might happen if the debugger is using too much time when trying to establish connection, and the CPU is constantly resetting.

If it is stuck in a reset loop, occurring early in the process of boot up, I'd recommend that you try to run nrfjprog recover while power cycling your board. For instance using a batch file on windows:

:loop
nrfjprog --recover -f nrf52
goto loop

 

Kind regards,

Håkon

[Manuel55]

Thanks Håkon,

After at least 100 attemps, I was finally able to recover those two devices with your batch file solution.
I have three PCBs. One of them has only the CPU soldered and it works fine. The othe two PCBs also have a few sensors and other peripherals. Those two PCBs are running into that bootloop everytime, I want to program them.

I'm currently checking which piece of peripheral causes this behaviour. Any idea what kind of GPIO behaviour could cause that?

Thanks and best regards,
Manuel

[Håkon Alseth]

Hi Manuel,

 

Glad to hear that you were able to recover the board. I would recommend that you add blocking assertions when developing, by adding the preprocessor define "DEBUG".

This will also give you more detailed info on where it has failed (line/file/err_code). You can read more about this here:

https://devzone.nordicsemi.com/b/blog/posts/an-introduction-to-error-handling-in-nrf5-projects

Kind regards,

Håkon

[Manuel55]

Hi Håkon,

Thank you for this link but I am not sure if its usefull, because it happens already at the flash operation. No code has executed yet. Or did I got you wrong?

Nevertheless I have dicovered a pattern. When I recover a chip, then I have to rebuild my application and then it works fine. When I want to debug without rebuilding, then the flash operation fails and the code starts at address 0xFFFFFFFE (disassembly). And there is also a hardfault (xPSR = 0x01000003). Why has rebuilding the code an impact on the starting point of a recovered device?

The bootloop behaviour has magically diappeared since I updated my J-Link version to the newest one...

Best regards,
Manuel

[Håkon Alseth]

Hi Manuel,

 

Manuel55 said:

Why has rebuilding the code an impact on the starting point of a recovered device?

Rebuilding your code should not have any impact. 

Manuel55 said:

The bootloop behaviour has magically diappeared since I updated my J-Link version to the newest one...

It sounds like this was the cause of your problems. If you have two debuggers, try both of them, on different computers if you run into this issue again in the future.

 

Kind regards,

Håkon

[Avi]

Hi

Both options didn't work.

I will ask to get  a new board.

Thanks for your support!

Avi