No IDCode detected error after RAM changes

[Konrad213]

Hi everyone!

I'm using nrf52832 SDK version 15.0 and softdevice S132 V6.0.0. I'm getting an error when trying to program our board:

"Failed to connect to target.

No idcode detected.

Please chack connection and Target Interface Type."

This happened after making some updates to the code. The change I think might be causing the problem is this one to the RAM:

I followed this solution: devzone.nordicsemi.com/.../nrf_shd_ble_enable-function-error-code-4-no-memeory-for-operation

But with these values: devzone.nordicsemi.com/.../error-4-nrf_error_no_mem-in-nrf52832

I could reprogram the board a couple of times with this code but eventually it got to the error message above and now I can't do anything.

I have a development board connected to another nrf52 where the VTG goes to VDD of the external board and the ground, SDIO and SDClock go to the corresponding parts on the external board.

I’m wondering if there’s any way to recover the external board?

[Vidar Berg]

Hi,

Are you using Keil uVision for programming by any chance? In that case, please check if "SW" is selected for the programming Port. The Debugger settings may have been reset to the default if you at some point changed the device type while trying to fix the no memory error. 

[Konrad213]

Nope using SEGGER, is there a similar setting there?

[Konrad213]

The first call is when the external board is connected and powered on. The second one is when the external board is shut down. Could I send it to you privately?

EDIT: Sent it over LinkedIn, couldn't message here. Again, I'm only having trouble reprogramming the board (connecting via J-Link. only the external board, the DK can be reprogrammed), the board is still functioning and running the code I programmed last time it worked. I think the issue happens after the board is programmed with the code I sent you and restarted but not sure. Might then be something with the boot-up messing up UART settings?

[Vidar Berg]

Thanks for providing your project. I was able to flash the FW with SES, indicating that your project settings are correct at least. I think it has to be a coincidence that the programming started to fail after you changed the RAM settings. The only scenario I know of that can cause the device to become bricked is if both readback protection is enabled and WD timer is initialized with timeout less than 1ms ([176] System: Flash erase through CTRL-AP fails due to watchdog time-out).

But I'm surprised that nrfjprog --recover doesn't seem to return anything when targetting your board. I don't think I've seen that before. Here are some suggestions for further troubleshooting:

- Update nrfjprog if you're using an old version. Latest is 10.4.1

- The on-board Jlink lite does not have a level shifter so the target chip must have be the same as VDD on the DK. Is it possible to supply the target board from the DK to ensure the same voltage?

- Make sure there's a GND connection between the two boards. 

- Program the hex file with nrfjprog and see if you get 'verification success': "nrfjprog --program application.hex --chiperase --verify", or if it behaves the same as --recover did. 

Hope this helps.

[Konrad213]

I doesn't break the board instantly for some reason, it took a couple of reprogramming and restarts before it broke in my case (I think). There is a GND connection, will get back to you on the voltage. I'm using 10.4.1 and this is the result, same as last time (first is with the power on to the external board and second with power off):

 

EDIT: Supplying voltage from the DK didn't help either.

[Vidar Berg]

I'm not saying the board is broken, but I'm also not sure why it can't be programmed. I don't believe it's related to RAM, UART, or other FW settings as errata #176 is the only known scenario where FW can potentially brick the device. 

Vidar Berg said:

But I'm surprised that nrfjprog --recover doesn't seem to return anything when targetting your board. I don't think I've seen that before. Here are some suggestions for further troubleshooting:

The behavior appears to have changed in a more recent version of nrfjprog. Previously it would return with an error if it failed to connect to the target, but now it just hangs. I confirmed it by connecting VTG to nRF_VDD on a DK here. So it seems like both SES and nrfjprog are failing to establish a connection in your case. 

[Konrad213]

Sorry I was a bit unclear. The board is not broken (it's still connecting over bluetooth to my phone) but it's not possible to reprogram. Any other ideas? Did you experience the same thing?

[Vidar Berg]

All the SES error and nrfjprog behavior tells us is that the debugger is not able to connect to the target chip. And that is my experience, usually related to wrong voltage levels or bad SWD connections. So it's easy to reproduce the error itself. But it's hard to say why your setup stopped working all of a sudden, unfortunately. Would it make sense to go over the connections again? And maybe you should try to replace the programming cables. 

[Konrad213]

This happened with two completely separate setups after we updated the code. The only part I could think would cause it was the RAM settings.

[Vidar Berg]

Strange that suddenly started failing on two separate setups, maybe it is the FW somehow. I noticed that pinreset is enabled on P0.21 in your project, to be sure, can you verify that this pin isn't being pulled low on the board? 

[Konrad213]

It's not being pulled low.