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?

[Vidar Berg]

I see, then it's less likely that the programming interface has inadvertently been changed to JTAG, but check the debugger settings to be sure:

 

Do you only get the error when attempting to program the external board, or do you also see it if you try programming the 52 on the development kit? Also, have you tried to program the board with nrfjprog?

[Konrad213]

Thanks for the response! It's same as yours. Only when programming the external board. Could it be something with messing up UART with the RAM settings? Will try nrfjprog

Update: Tried nrfjprog and it's not working, no errors though so I assume it's programming the development kit.

[Vidar Berg]

The debugger should always be able to connect regardless of how the FW running on the chip is configured. Wrong RAM settings may for instance lead to a fault exception, but the debugger should still be able to connect and re-program it. 

Maybe you can try to reduce the clock speed and see if that helps. nrfjprog use 2khz by default, compared to 4khz in SES. This might be necessary if you use long programming cables. Also, if you maybe could try another SDK SES example to see if that works.  

[Konrad213]

Doesn't work. We had the same behavior on multiple boards. After reprogramming the error starts showing up. We tested on multiple boards, multiple DK, multiple laptops. Is there any way to recover the exteral board? nrfjprog --recover does nothing but there's also no error so I assume it resets the DK. Without having dfu set up, is there another way of connecting to the external board to program it?

[Vidar Berg]

Hi,

Would it be possible to upload the SES project here? I would like to see if I can replicate it here.

nrfjprog --recover will perform a full chip erase, same as nrfjprog --eraseall. The flash should be erased if no errors were returned.  

When programming hex files with nrfjprog, you may use the --verify option when programming  guarantee that the image was programmed correctly:

    nrfjprog --program <>.hex --verify --reset

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