• State Verified Answer
  • Replies 9 replies
  • Subscribers 74 subscribers
  • Views 3960 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.

Parents
  • 0

    Hi,

     

    Based on the serial number, it seems that you are using a nRF52-DK to program external devices.

    In this setup, where the nRF52-DK is acting as the programmer to an external board, it is very important that the external board is powered with the same voltage as the nRF52-DK (3.0V)

    Are you powering your custom board from the DK itself, or is it battery powered? If battery powered, try replacing the battery to see if you now can communicate with the board.

     

    PS: your nrfjprog installation is quite old. You should consider updating it: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools/Download 

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,

    Thanks for your response. Yes, the external board is being powered with 3.3V, and i have tried multiple batteries. The remaining blank, unprogrammed prototype boards are functioning normally with the same setup. They are visible in nRFgo upon connecting and I am able to upload the merged hex file (with DFU bootloader + Soft Device + Application) to these boards. It's only the two that I had erased and then uploaded the softdevice hex alone that are no longer visible after connecting the battery and the nRF52-DK for programming.

    Will update nrfjprog - thanks for catching that.

    Regards,
    Matt

  • 0 in reply to matomback

    Hi Håkon,

    It seems the problem was using nRFgo Studio specifically. I was able to get another of the prototype boards to work correctly after programming our merged hex application and clearing and then loading the soft device using the command "nrfjprog -f nrf52 --program s132_nrf52_6.1.1_softdevice.hex --chiperase". 

    I was aware that nRFgo studio was deprecated and can cause issues when using with the a DFU bootloader application. However I thought that this would be a run-time error rather than something that could brick the device just by clearing the application and programming the soft device hex.

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

    Thanks

  • 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

Reply Children
No Data
Related
Terms of service