• State Verified Answer
  • Replies 33 replies
  • Subscribers 74 subscribers
  • Views 5397 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 237863
Options
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"

NANDHU

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
  • 0

    Hi Nandhu,

     

    After recovering the device, did you flash the same .hex file to it again?

    If there is a assertion occurring in the very beginning, it will be hard to recover again.

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

     

    I also see that there are several mechanical links between the debugger and the nRF, are all these connections tested to be working?

    PS: You should not use normal tape on electronics, as tape will generate a high ESD spike when applied, moved, or removed, and this can damage electronics. You should use ESD-safe tape.

    Kind regards,

    Håkon

Reply
  • 0

    Hi Nandhu,

     

    After recovering the device, did you flash the same .hex file to it again?

    If there is a assertion occurring in the very beginning, it will be hard to recover again.

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

     

    I also see that there are several mechanical links between the debugger and the nRF, are all these connections tested to be working?

    PS: You should not use normal tape on electronics, as tape will generate a high ESD spike when applied, moved, or removed, and this can damage electronics. You should use ESD-safe tape.

    Kind regards,

    Håkon

Children
No Data
Related
Terms of service