• State Verified Answer
  • Replies 9 replies
  • Subscribers 74 subscribers
  • Views 3972 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 239467
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Custom boards bricked after erasing and uploading Soft Device hex using nRFgo Studio

matomback

We have a set of custom boards I am working on debugging. I was able to get our software onto the device via nrf jprog tool by uploading a merged hex file (with SD + bootloader + application). The GPIO appeared to be working normally but I was unable to connect to the modules over Bluetooth. So I tried to upload a simple custom service application (based on ble_app_template) to test the BLE connection with nothing else enabled. I used nRFgo to erase all on the custom board and then attempted to flash the softdevice hex (s132 v6.1.1). After doing so the board immediately disappeared from the nRFgo interface and showed 'no device detected' (see image below).

Now I am unable to access/program or recover the board, using both nRFgo and nrf jprog tool. I tried --recover, --eraseall, and --reset commands via command line. I get the following error message when trying to reprogram "JLinkARM DLL reported an error..." and the following error message when trying to recover "Cannot connect to any nRF device. Please make sure a device is connected to the debugger and supplied." This happened the exact same way to two of our custom modules, which were both running properly with our software (although not connecting over BLE) before the error occurred.

Any ideas as to what the issue could be / how to recover these custom boards?

I will include the log output below after trying to program via nrf jprog:

--------------------------------------------------------------------------------
C:\Program Files (x86)\Nordic Semiconductor\nrf5x\bin\nrfjprog.exe -f nrf52 --program neop_full_pack.hex --chiperase -r --log
nrfjprog verion 8.5.0
--------------------------------------------------------------------------------
FUNCTION: open_dll.
FUNCTION: open_dll.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_without_snr.
FUNCTION: enum_emu_snr.
Device "NRF52832_XXAA" selected.
FUNCTION: read_device_version.
FUNCTION: read_device_version.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.
FUNCTION: close_dll.
FUNCTION: close_dll.

  • 0 in reply to matomback

    Hi Matt,

    matomback said:
    Thanks for your support. Unfortunately the looping batch script did not seem to work. I tried for a while with both "nrfjprog -e" and "nrfjprog --recover". Still getting the same error messages and unable to see or access the external nRF board. Is there any other command I should try? Or another way to detect or recover the device if it's asserting the way you describe?

    When this script is running, did you try toggling the power to the custom board simultaneously (ie: removing and inserting the battery) and see if it then was able to successfully recover it?

    Did you also upgrade nrfjprog?

    matomback said:
    With this information in mind, is there anything specific that nRFgo studio could have done to cause the issues with the boards? Anything else I can try in order to recover them? I am still unable to see or program via any of the tools (nrfjprog, nRF connect, nRFgo studio).

    nRFgo studio is deprecated, and is not recommended to use with the nRF5-series devices, but it shouldn't have this effect on the boards.

    Did you enable any specific programming options in nRFgo Studio?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,

    I did. I was continuously removing and inserting the battery, and tried to do so at different intervals/timing but was unable to recover the device. I also did upgrade nrfjprog which did not seem to have any effect.

    Yes I was thinking the same. I will stay away from nRFgo Studio from now on but I'm surprised the boards could have been bricked like this while using it. I had not enabled any specific programming options and just used the default settings after opening the nRFgo Studio application.

    Any other thoughts or ways I can try to debug/troubleshoot the issue?

    Thanks,

    Matt

  • 0 in reply to matomback

    Hi Matt,

     

    Sorry for the late reply.

    I've checked around with my colleagues, and we have not gotten any reports that boards programmed through nrfgo studio is not working. We have this one, where "erase all" had to be issued prior to programming (which is recommended anyway) :

    https://devzone.nordicsemi.com/f/nordic-q-a/54806/issue-with-nrf52832-firmware-installation

     

    Could you try to connect via J-Link Commander, and see if it is able to detect the nRF52832 (cortex m4 core) on the non-working boards?

     

    Kind regards,

    Håkon

  • +1 in reply to Håkon Alseth

    Hi Hakon,

    Sorry dropped the ball on this one. We eventually discovered that a hardware issue was the culprit. A mistake in assembly (incorrect passive component placed) caused the problem. Though the tip to discontinue our use of the deprecated nRFgo studio was helpful and appreciated.

    Best,
    Matthew

Related
Terms of service