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

    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 Matt,

     

    matomback said:
    The remaining blank, unprogrammed prototype boards are functioning normally with the same setup.

    This indicates that the physical setup is OK.

    Could it be that the firmware you loaded into the devices are asserting early on in the process? The default assertion behavior is to issue a soft-reset, which lowers the timing window for the debugger to access the device. If this has happened with your devices, you can try to loop "nrfjprog -e" while you cycle the power to the custom board (plug in and out the battery). A batch script for this can be found here:

    https://devzone.nordicsemi.com/f/nordic-q-a/45078/nrf52832-not-connected-anymore-after-first-trying-to-debug-keil/177579#177579

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,

    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?

    Or could the issue be something else? I had performed an "erase-all" within nRFgo to remove the code on the board before I loaded the soft device, which bricked the board. Could this have left some element of the DFU bootloader or bootloader settings or other aspect of the application on the device? Or would the external nRF have been clear at this point?

    I could try to use nrfjprog to program the soft device alone onto a blank board that hasn't been programmed yet... if that works it would seem the issue was caused via nRFgo or by erasing the merged application before loading the soft device. But we only have 10 prototype boards and until I can recover the bricked boards I would like to be somewhat careful in programming the others!

    Looking forward to your thoughts. Any additional feedback or guidance is appreciated.

    Thanks!

    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

Related
Terms of service