This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Cannot recover with NRFgo: "Could not read AHB-AP Id. Could not connect to target."

See subject. The softdevice is currently installed on the chip (v6.0.0-1.alpha)

I searched online, and found some information that the security state of the chip has been set to "locked". Is this true? How to unlock it?

Thanks! Jamie

  • No, this error does not mean that the device has been locked in any way. If the recover functionality consistently doesn't work, you can try to open J-Link Commander from the start menu, and write the following:

    
    r
    w4 4001e504 2
    w4 4001e50c 1
    w4 4001e514 1
    qc
    
    

    This basically just does an erase all, by manually writing to the registers, but we've seen previously that sometimes it works to do this manually even when nRFgo Studio is not able to do the same.

  • Thanks for the reply--I will give your suggestion a try.

    We need to understand what caused this state (the chip no longer was running it's firmware even). In the case of production, we need to know what the potential causes of such a situation, how to prevent it, and how to handle it in firmware if it does happen to a customer's device--any suggestions here?

    Thanks! Jamie

  • Which firmware were you running on the chip when this happened?

    The only way I'm aware that can put the chip in such state is to go into system off without any wakeup sources. There should be no reason to put a device into such state in an actual program, so this isn't really something you should need to think about from an end-user's perspective.

    If you have a firmware build that is consistently able to put the chip into such state, I'd be very happy to take a look on it.

  • I was running the stock BLE Heart Rate Service app that comes with the Nordic SDK (which I believe is programmed to go into system off mode after 3 minutes or so of inactivity). The soft device that was installed along with the firmware was the newest one--6.0.0-alpha.

    Thanks, Jamie

  • As I said, as long as you've set a wake-up source before entering system off, this will not happen, so I can't imagine this being a problem that a potential end-user would face.

    If you don't have any further questions, I'd be happy if you could accept my initial answer as accepted, if it solved the problem.

Related