This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ISSUES DUE TO "UNABLE TO FIND OR OPEN THE JlinkARM.dll"

HI,

  •  We are mainly using "nRFgo Studio" and "nRF Connect" application for erasing and flashing codes to our custom board and its taking place successfully for a long time.
  • The hardware tools we are using for flashing the code is "J-LINK BASE " version 10.1.
  • But now  we can't able to flash or erase the code to our custom board either with "nRFgo Studio" or nRF  Connect.I don,t known why its happening?

When i tried to erase the code in our custom board using "nRFgo Studio"

When i tried to read our custom board using "nRF_Connect" its not reading look the below screen shot

DOUBTS

  • What is the reason behind these issues?
  • Is it a problem with our custom board or with jlink tool?
  • What are the solution for these problems?

Please reply as soon as you can possible . Its a major issue with us.

Parents
  • Håkon Alseth said:
    After recovering the device, did you flash the same .hex file to it again?

     After  the device  is recovered we didn't flashed any hex to the device. We just tried to read the device using nRF_Connect but  the device is not detecting at all

    Look the below screen shot of nRF_Connect  .

    We aren't able to read the device with  no hex code in it.

    We also  tried to write the  code to the device ,the same issue showed up

     Please have a look in the screen shot

    The device is not detecting.

     

    Håkon Alseth said:
    For debugging purposes, try adding a nrf_delay_ms(100); in the top of your main, or add preprocessor define "DEBUG" to your project to enable blocking assertion

     We already added the "DEBUG" pre processor define in the project.

     

    Håkon Alseth said:
    I also see that there are several mechanical links between the debugger and the nRF, are all these connections tested to be working?

     There is no issues in mechanical links  between the debugger and the nrf because we are able to flash the code to our older version  boards with the same debugger . The issues is showing only in our latest version boards.Also we have cross checked the mechanical links between the debugger and nrf and its showing good.

Reply
  • Håkon Alseth said:
    After recovering the device, did you flash the same .hex file to it again?

     After  the device  is recovered we didn't flashed any hex to the device. We just tried to read the device using nRF_Connect but  the device is not detecting at all

    Look the below screen shot of nRF_Connect  .

    We aren't able to read the device with  no hex code in it.

    We also  tried to write the  code to the device ,the same issue showed up

     Please have a look in the screen shot

    The device is not detecting.

     

    Håkon Alseth said:
    For debugging purposes, try adding a nrf_delay_ms(100); in the top of your main, or add preprocessor define "DEBUG" to your project to enable blocking assertion

     We already added the "DEBUG" pre processor define in the project.

     

    Håkon Alseth said:
    I also see that there are several mechanical links between the debugger and the nRF, are all these connections tested to be working?

     There is no issues in mechanical links  between the debugger and the nrf because we are able to flash the code to our older version  boards with the same debugger . The issues is showing only in our latest version boards.Also we have cross checked the mechanical links between the debugger and nrf and its showing good.

Children
No Data
Related