[SOLVED]Linux: Unable to connect to J-Link on board nRF51822 Evaluation Kit

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Has anyone successfully use J-Link Commander to load the soft_device into memory starting at address 0x00000, program code starting at 0x20000, and successfully run a BLE program on the nRF51822?
    Yes.

    First, you have to covert the Nordic softdevice hex file into *two* binaries: the softdevice part and the UICR part. You can use objcopy for this, the following Makefile fragments are from Nordic.

    Source Code

    1. $(OBJCOPY) -Iihex -Obinary --remove-section .sec2 $(SOFTDEVICE) $(SOFTDEVICE_OUTPUT:.hex=_mainpart.bin)
    2. $(OBJCOPY) -Iihex -Obinary --remove-section .sec1 $(SOFTDEVICE) $(SOFTDEVICE_OUTPUT:.hex=_uicr.bin)


    You will also have to compile your code to a bin.

    Then you perform the following steps:
    1. erase the entire flash
    2. burn the UICR
    3. burn the softdevice
    4. burn your desired code


    Here is a rough transcript of the commands:

    Source Code

    1. J-Link>r
    2. ..
    3. J-Link>device nrf51822
    4. ..
    5. J-Link>speed 1000
    6. ..
    7. # erase the entire flash
    8. J-Link>w4 4001e504 2
    9. J-Link>w4 4001e50c 1
    10. J-Link>w4 4001e514 1
    11. J-Link>r
    12. # enable the flash for writing
    13. J-Link>w4 4001e504 1
    14. J-Link>loadbin my-uicr.bin 0x10001000
    15. ..
    16. J-Link>loadbin my-softdevice.bin 0
    17. ..
    18. J-Link>loadbin my-code.bin 0x20000
    19. ..
    20. J-Link>r
    21. J-Link>g
    22. J-Link>exit
    Display All

    The post was edited 1 time, last by vonkil ().

  • For what it's worth, this still happens on version 4.60 as well. As mentioned, this is OS X Mountain Lion, and libusb is the latest from macports. I have also verified that the board still works under Windows Vista, so I doubt it is hardware error. Is there anything I could do to try to determine what the cause is?
    I was having the same problem with V4.60 on OSX Mountian lion with libusb from macports. I connected the chip to a windows machine, opened up nrfgoStudo, clicked through nr51822 programming->Erase all program memory, and then once I reconnected the nrf51822 to my Mac and ran JLink Commander it was able to find the core just fine.
  • riblankman wrote:

    For what it's worth, this still happens on version 4.60 as well. As mentioned, this is OS X Mountain Lion, and libusb is the latest from macports. I have also verified that the board still works under Windows Vista, so I doubt it is hardware error. Is there anything I could do to try to determine what the cause is?
    I was having the same problem with V4.60 on OSX Mountian lion with libusb from macports. I connected the chip to a windows machine, opened up nrfgoStudo, clicked through nr51822 programming->Erase all program memory, and then once I reconnected the nrf51822 to my Mac and ran JLink Commander it was able to find the core just fine.


    Thank you so much! Now it detects the CPU just fine. It seems a bit weird that anything in the flash could cause JLinkExe to fail to find the CPU, though...
  • SEGGER - Alex wrote:

    JLinkExe -SelectEmuBySN 580011111


    I'd just like to add that the JLinkExe.command shell script wrapper which comes with the OS X release discards all command-line arguments when calling JLinkExe. I propose replacing the last part of the script with this:

    Source Code

    1. if test "${MACOSX_VERSION}" == "10.5"
    2. then
    3. exec arch -i386 ./JLinkExe "$@"
    4. else
    5. exec ./JLinkExe "$@"
    6. fi


    The important part here is "$@", which passes on all command-line arguments given to the script while keeping then properly quoted. The "exec" is not as important, it just saves you a fork() which makes it a bit easier to use dtruss and similar tools.
  • Quote edited to make it a bit more compact:

    vonkil wrote:

    However, my original point stands. On OSX, with no arguments the board is not found.

    Source Code

    1. $ ./JLinkExe
    2. SEGGER J-Link Commander V4.59d ('?' for help)
    3. Compiled Jan 7 2013 19:12:12
    4. Can not connect to J-Link via USB.


    The same is true when using the '-SelectEmuBySN' argument.

    Source Code

    1. $ ./JLinkExe -SelectEmuBySN 480200656
    2. SEGGER J-Link Commander V4.59d ('?' for help)
    3. Compiled Jan 7 2013 19:12:12
    4. Could not find emulator with USB serial number 480200656.



    After playing around with it a bit, I was able to get it to auto-detect the JLink by using “-SelectEmuBySN 1”. This seems to trick JLinkExe into scanning the USB bus properly, and subsequently detecting a device:

    Source Code

    1. knuta@knuta-mbp ~/JLink_MacOSX_V460 $ ./JLinkExe.command -SelectEmuBySN 1
    2. SEGGER J-Link Commander V4.60 ('?' for help)
    3. Compiled Jan 14 2013 10:51:35
    4. DLL version V4.60, compiled Jan 14 2013 10:51:31
    5. Firmware: J-Link OB-SAM3U128 V1 compiled Jan 7 2013 18:12:29
    6. Hardware: V1.00
    7. S/N: (redacted)
    8. VTarget = 3.300V
    9. Info: Could not measure total IR len. TDO is constant high.
    10. Info: Could not measure total IR len. TDO is constant high.
    11. No devices found on JTAG chain. Trying to find device on SWD.
    12. Info: Found SWD-DP with ID 0x0BB11477
    13. Info: FPUnit: 4 code (BP) slots and 0 literal slots
    14. Info: Found Cortex-M0 r0p0, Little endian.
    15. Cortex-M0 identified.
    16. JTAG speed: 100 kHz
    Display All


    After discovering this, I inspected JLink.log, and noticed that “-SelectEmuBySN” seems to not only be used to select the serial number, but it will fall back to the old method of selecting the USB port when called with a number less than 4.

    Thus, another way of making it detect the JLink, which doesn't require command-line arguments and can be put inside a JLink script, is to issue the command “usb 1”, like this:

    Source Code

    1. nuta@knuta-mbp ~/JLink_MacOSX_V460 $ ./JLinkExe.command
    2. SEGGER J-Link Commander V4.60 ('?' for help)
    3. Compiled Jan 14 2013 10:51:35
    4. Can not connect to J-Link via USB.
    5. J-Link>usb 1
    6. Connecting to J-Link via USB (Port: 1)
    7. DLL version V4.60, compiled Jan 14 2013 10:51:31
    8. Firmware: J-Link OB-SAM3U128 V1 compiled Jan 7 2013 18:12:29
    9. Hardware: V1.00
    10. S/N: (redacted)
    11. VTarget = 3.300V
    12. Info: Could not measure total IR len. TDO is constant high.
    13. Info: Could not measure total IR len. TDO is constant high.
    14. No devices found on JTAG chain. Trying to find device on SWD.
    15. Info: Found SWD-DP with ID 0x0BB11477
    16. Info: FPUnit: 4 code (BP) slots and 0 literal slots
    17. Info: Found Cortex-M0 r0p0, Little endian.
    18. Cortex-M0 identified.
    19. JTAG speed: 100 kHz
    Display All


    I'd personally opt for “-SelectEmuBySN”, though, considering that “usb 1” can only be used after the JLink has done an initial, futile attempt.

    It is also worth noting that using “-SelectEmuBySN 0” or “usb 0” doesn't work. This is odd, considering that 0 is what I would select in selemu.
  • still can't program nrf51822 from MacOSX

    I have a development kit for the nrf51822 (running the chip at 3.3V) as well as a prototype device I'm working on (running the chip at 1.8V). I have both the jlink programmer that comes with the development kit as well as a JLink Pro (necessary for programming at 1.8V), and I'm programming just fine using keil on a windows machine.

    Vonkil, I tried the method you suggested, turned my .hex files into .bin, and went through the steps you described but when I get to writing the uicr.bin to 0x10001000, the programming either never ends or takes tens of minutes. Programming just stalls at line 5 in the code box below. Does anyone know why this would be happening? Vonkil, are you using OSX? Thanks.

    C Source Code

    1. J-Link>w4 4001e504 1
    2. Writing 00000001 -> 4001E504
    3. J-Link>loadbin /Users/me/uicr.bin 0x10001000
    4. Loading binary file... [/Users/uicr.bin]
    5. Writing bin data into target memory @ 0x10001000.
  • Vonkil, I tried the method you suggested, turned my .hex files into .bin, and went through the steps you described but when I get to writing the uicr.bin to 0x10001000, the programming either never ends or takes tens of minutes. Programming just stalls at line 5 in the code box below. Does anyone know why this would be happening? Vonkil, are you using OSX? Thanks.
    Yes, I am using OSX, and the steps I described earlier work on my Nordic board. It's not consistent, but usually if I try waving a dead chicken, it eventually works.

    Sorry, I don't know why your OSX and Nordic board does not respond the same way as mine. However, it's clear to all that Segger still has a lot more work ahead to get the OSX and Linux tools workable.

    Of all the platforms that might be useful with the Nordic parts, Windows is probably last on the list. Android/Linux, iOS, and OSX rank way higher for potential BLE deployments. That Nordic and Segger are pushing Windows for developing with this board seems quite silly to me.

    Segger, this situation is starting to get desperate... can we get an update on fixing the JLink tools for Linux and OSX?
  • RE: still can't program nrf51822 from MacOSX

    riblankman wrote:

    Vonkil, I tried the method you suggested, turned my .hex files into .bin, and went through the steps you described but when I get to writing the uicr.bin to 0x10001000, the programming either never ends or takes tens of minutes. Programming just stalls at line 5 in the code box below. Does anyone know why this would be happening? Vonkil, are you using OSX? Thanks.


    Vonkil's example assumes that the UICR is in section 2, but in 3.0.0-1.beta it is in section 3. He probably did this using a previous release of the softdevice.

    Before going on, it is probably a good idea to explain why we need to split the hex file in the first place. The reason for this, is that unlike .bin, .hex allows you to place the data in disconnected sections. With .bin, the file is just in raw binary format, and cannot have gaps. Since the UICR is just control data which is in a magic part of memory, there is a significant gap between the actual stack and the UICR in the hex file. If you just convert the .hex file directly to .bin and let objdump fill the gaps with zeroes, you will get a file of about 256MB. This obviously doesn't fit on the chip.

    Vonkil's commands only excluded either section 1 or 2 of the hex files, but since the UICR was in section 3, both one part of the stack and the UICR were always in the output. The result was two .bin files of about 256MB, none of which can be programmed on the device.

    A more appropriate conversion command for 3.0.0-1.beta would be this:

    Source Code

    1. objcopy -Iihex -Obinary --remove-section .sec3 S110_nRF51822_3.0.0-1.beta_softdevice.hex S110_nRF51822_3.0.0-1.beta_softdevice_mainpart.bin
    2. objcopy -Iihex -Obinary --only-section .sec3 S110_nRF51822_3.0.0-1.beta_softdevice.hex S110_nRF51822_3.0.0-1.beta_softdevice_uicr.bin


    To sanity-check the results, verify that both files are significantly smaller than 1MB. The size of the UICR file should be exactly 32 bytes.

    Now on to debug the segmentation fault I get from JLinkExe when I try to program anything at 0x20000...

    The post was edited 1 time, last by knuta ().

  • Now on to debug the segmentation fault I get from JLinkExe when I try to program anything at 0x20000...


    Yep, you were right about softdevice 3.0, thanks a lot! well, things work a little better now, but I get the same seg faults as you... I also normally get a RAMCode/RAM check error when I try to program at 0x0--does anyone know what that means?

    my ouput, in case it helps segger detect the issue:

    C Source Code

    1. J-Link>loadbin /Users/me/uicr.bin 0x10001000
    2. Loading binary file... [/Users/me/uicr.bin]
    3. Writing bin data into target memory @ 0x10001000.
    4. J-Link>loadbin /Users/me/mainpart.bin 0x0
    5. Loading binary file... [/Users/me/mainpart.bin]
    6. Writing bin data into target memory @ 0x00000000.
    7. ****** Error: Failed to prepare for programming.
    8. Failed to execute RAMCode for RAM check!
    9. ...
    10. J-Link>loadbin /Users/me/code.bin 0x20000
    11. Loading binary file... [/Users/me/code.bin]
    12. Writing bin data into target memory @ 0x00020000.
    13. ./JLinkExe.command: line 26: 4927 Segmentation fault: 11 ./JLinkExe
    Display All
  • Hi all,

    Could you please for future threads do not mix up different problems in the same thread, since this makes it really difficult to follow the thread and check what still is open and what is already resolved.

    For all:

    SelectEmu command is necessary to connect to J-Link-OB on nRF51 eval board:
    This is not reproducible here. We tried it multiple times and it just works fine. The J-Link is automatically found and J-Link Commander connects to it automatically.
    No further actions / commands in J-Link Commander are required.

    J-Link OB on nRF51 eval board is not detected by J-Link Commander under Linux:
    We already fixed that internally. There is a new version planned for today/tomorrow which fixes this problem.

    Segmentation fault when trying to program flash via J-Link Commander (happens on Mac OS X only):
    Already fixed internally. Will also be part of the new version.

    JLinkExe.command shell script wrapper which comes with the OS X release discards all command-line arguments:
    We will check & change. Can also be part of the new version.

    Remaining limitation for the next Mac/Linux version:
    Only one J-Link connected to the same PC via USB at the same time is supported.
    For now, having multiple J-Links connected via USB is supported on Windows only.
    This will be lifted in a future version of the Mac & Linux package, but I can not give you any specific date yet. Will be some time this year.

    Hope I did not miss any other open issue.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Alex wrote:

    Hope I did not miss any other open issue.


    It was also mentioned that it is fairly easy to semi-brick the board by flashing it, after which JLinkExe on OS X will no longer detect the CPU. I have also experienced that it couldn't even detect the J-Link itself. In all cases, erasing the chip from Windows made J-Link able to connect to it again. For instance, after programming the device with S110_nRF51822_3.0.0-1.beta_softdevice.hex and the BLE proximity example from Nordic, JLinkExe under OS X could not detect the CPU. JLink.exe on Windows had no problems. In order to get the board up in OS X, I had to plug it into a Windows machine and erase everything using nRFGo Studio to be able to detect the CPU.
  • Hi,

    For instance, after programming the device with S110_nRF51822_3.0.0-1.beta_softdevice.hex and the BLE proximity example from Nordic,
    JLinkExe under OS X could not detect the CPU. JLink.exe on Windows had no problems.

    Does not really make sense to me because both libraries (Windows & Mac) are based on almost the same source.
    Where do we get the hex file from? Can someone provide it?
    (We do not want to search for all projects on the NordicSemi page and setup the complete environment etc. just to may find the hex file you guys are referring to.)

    If someone can provide a sample scenario with all that is needed to reproduce the problem, we will certainly have a look into this.


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi all,

    We have just released V4.62 for Mac & Linux.
    In this version, the following issues have been fixed:

    - J-Link OB on nRF51 eval board is not detected by J-Link Commander under Linux:
    - Segmentation fault when trying to program flash via J-Link Commander (happens on Mac OS X only):
    - JLinkExe.command shell script wrapper which comes with the OS X release discards all command-line arguments:
    - 45-jlink.rules updated (J-Links with CDC functionality were not covered).

    Please feel free to try it out and provide some feedback :)


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Alex wrote:

    SelectEmu command is necessary to connect to J-Link-OB on nRF51 eval board:
    This is not reproducible here. We tried it multiple times and it just works fine. The J-Link is automatically found and J-Link Commander connects to it automatically.
    No further actions / commands in J-Link Commander are required.


    The new version works fine under Linux and Windows, but I still have problems under OS X. I just discovered that Windows and Linux tells me the board has serial number 123456, which I believe indicates that it is configured to use the deprecated “USB number” naming scheme instead of serial numbers. I do not know why, and I have not configured it this way intentionally. To be specific, this is what dmesg on my Linux machine says about my device (yes, I know OS X is the one having problems, but I don't know how to list such info there):

    Source Code

    1. [ 584.172207] usb 1-6: new high-speed USB device number 4 using ehci_hcd
    2. [ 584.305636] usb 1-6: New USB device found, idVendor=1366, idProduct=0105
    3. [ 584.305647] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    4. [ 584.305654] usb 1-6: Product: J-Link
    5. [ 584.305660] usb 1-6: Manufacturer: SEGGER
    6. [ 584.305665] usb 1-6: SerialNumber: 000000123456


    Maybe you can reproduce the issue with a similarly configured J-Link?

    All the other issues are fixed, and I have successfully programmed both the SoftDevice and program under both OS X and Linux. There are some problems reading the RAM config sometimes, but I believe this is related to my script not clearing the UICR properly, and not a JLinkExe bug. Good work!

    PS: You can also disregard my earlier comment about being able to brick the board from Linux but it still working under Windows. The difference seems to be that I unplugged the board to move it to the Windows machine. I'll make a separate thread if I actually encounter a reproducible problem related to this.
  • riblankman wrote:

    I also normally get a RAMCode/RAM check error when I try to program at 0x0--does anyone know what that means?

    Source Code

    1. J-Link>loadbin /Users/me/uicr.bin 0x10001000
    2. Loading binary file... [/Users/me/uicr.bin]
    3. Writing bin data into target memory @ 0x10001000.
    4. J-Link>loadbin /Users/me/mainpart.bin 0x0
    5. Loading binary file... [/Users/me/mainpart.bin]
    6. Writing bin data into target memory @ 0x00000000.
    7. ****** Error: Failed to prepare for programming.
    8. Failed to execute RAMCode for RAM check!

    I believe this is because the SoftDevice memory area has been protected by the UICR, so we need to clear it before we are allowed to write to that memory again.

    Your script suggests that you are always overwriting the UICR before loading the SoftDevice, but the writes are probably actually happening in the opposite order. I read somewhere that the actual writing is only scheduled by loadbin and actually done “on demand” when you do reset or similar. It's probably ordering the writes so it actually writes the UICR after the SoftDevice.

    Alas, I am unable to find the documentation I think I read stating that the writes are lazy, so I might be imagining things. It would however explain the behavior you are seeing.

    If you clear the entire device using nRFGo Studio, I believe you will be able to program the SoftDevice once, before it gets write-protected again.
  • knuta wrote:

    Source Code

    1. [217129.812561] cdc_acm 1-6:1.0: This device cannot do calls on its own. It is not a modem.
    2. [217129.812713] cdc_acm 1-6:1.0: ttyACM0: USB ACM device
    3. [217129.814803] usbcore: registered new interface driver cdc_acm
    4. [217129.814808] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters


    The nRF51822 is clearly not a modem, but it seems the Linux kernel thinks the USB serial port it exposes is one. This blocks the device so JlinkExe cannot access it, and instead of saying “Device is busy” as it should, it just says failed to connect. This can be solved easily by unloading the cdc_acm driver using modprobe -r or rmmod, and you can avoid it happening again by banning the driver in the modprobe configuration.


    I tested the latest release, and with version 4.62 of the Linux tools, cdc_acm and JLinkExe are able to co-exist peacefully. That means you probably want to have it enabled, because it is probably what gives you the UART output from the device.
  • Congratulations to the Segger folks. I can confirm the Linux tools are working with the nRF51822-EK on Fedora 17, 64-bit (although I had to hack in the older libreadline.so.5 to get it running).

    I can also confirm the OSX tools work but it will still sometimes segfault, and always fails to find the J-Link unless you use the trick mentioned earlier in the thread: "-SelectEmuBySN 1".
  • Linux version of JLinkExe works on Gentoo x86_64 machine

    Confirming also that the V4.62 revision of JLinkExe is working great on my Gentoo x86_64 machine.

    I noticed that new firmware was loaded the first time I ran it:
    SEGGER J-Link Commander V4.62 ('?' for help)
    Compiled Jan 25 2013 15:26:04
    Updating firmware: J-Link OB-SAM3U128 V1 compiled Jan 7 2013 18:12:29
    Replacing firmware: J-Link OB-SAM3U128 V1 compiled Aug 1 2012 10:57:06
    Waiting for new firmware to boot
    New firmware booted successfully
    DLL version V4.62, compiled Jan 25 2013 15:26:02
    Firmware: J-Link OB-SAM3U128 V1 compiled Jan 7 2013 18:12:29
    Hardware: V1.00
    S/N: xxxxxxxxxx
    VTarget = 3.300V
    Info: Could not measure total IR len. TDO is constant high.
    Info: Could not measure total IR len. TDO is constant high.
    No devices found on JTAG chain. Trying to find device on SWD.
    Info: Found SWD-DP with ID 0x0BB11477
    Info: FPUnit: 4 code (BP) slots and 0 literal slots
    Info: Found Cortex-M0 r0p0, Little endian.
    Cortex-M0 identified.
    JTAG speed: 100 kHz
    I now am able to build a nRF51822 target image using a GNU toolchain running natively on Linux, and load, run, and debug (single-step, breakpoints) the image completely in a Linux environment! Thanks to the Segger guys for providing this capability.

    I haven't been able to get the JLinkGDBServer to work however, but I probably don't have things configured properly just yet. Here is what I get when I run it:
    SEGGER J-Link GDB Server V4.62

    JLinkARM.dll V4.62 (DLL compiled Jan 25 2013 15:26:02)

    The server has been started with the following settings:
    ---Server related settings---
    GDBInit file: none
    Listening port: 2331
    SWO thread listening port: 2332
    Accept remote connection: localhost only
    Logfile: on
    Verify download: off
    Init regs on start: on
    Silent mode: off
    Single run mode: off
    ---J-Link related settings---
    J-Link script: none
    Target interface: JTAG
    Host interface: USB
    Target endian: little
    Target interface speed: 1000kHz

    Connecting to J-Link...
    J-Link is connected.
    Firmware: J-Link OB-SAM3U128 V1 compiled Jan 7 2013 18:12:29
    Hardware: V1.00
    S/N: xxxxxxxxxx
    Checking target voltage...
    Listening on TCP/IP port 2331
    Connecting to target...ERROR: Could not connect to target.
    Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
    Connecting to J-Link...
    J-Link is connected.
    Firmware: J-Link OB-SAM3U128 V1 compiled Jan 7 2013 18:12:29
    Hardware: V1.00
    S/N: xxxxxxxxxx
    Checking target voltage...
    Restoring target state and closing J-Link connection...
    Shutting down...


    Note that it says there is no .gdbinit file and no J-Link script, but in fact those files are residing in my home directory. However, an strace shows no evidence of the program attempting to access them. So far it is a puzzle. I will keep you posted as I continue investigating...

    --ken
  • Hi Ken,

    The problem is simple:
    You do not have the correct target interface selected in GDBServer.
    You have selected JTAG while on the nRF51 board only SWD is supported.

    Just start JLinkGDBServer with the following command line:
    ./JLinkGDBServer -if SWD -device nRF51822 -speed 4000


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.