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