• State Not Answered
  • Replies 8 replies
  • Subscribers 68 subscribers
  • Views 6885 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 225692
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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...

Parents
  • 0

    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

  • 0 in reply to Håkon Alseth

    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

  • 0 in reply to Manuel55

    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

Reply
  • 0 in reply to Manuel55

    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

Children
Related