[SOLVED] JLinkExe return code 1 when executing script

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

  • [SOLVED] JLinkExe return code 1 when executing script

    Hello,
    I have a script, that runs without errors:

    Source Code

    1. device nRF51422_xxAB
    2. loadbin fag_kommunikationsmodul.bin, 0x00020000
    3. r
    4. g
    5. q


    But the JLinkExe on OSx returns with 1, indicating an error

    Source Code

    1. > JLinkExe flash.jlink
    2. SEGGER J-Link Commander V4.88a ('?' for help)
    3. Compiled Jul 17 2014 18:24:06
    4. Script processing completed.
    5. > echo $?
    6. 1


    So the following code would indicate an error:

    Source Code

    1. JLinkExe flash.jlink || echo "error"


    If I start JLinkExe without argument and execute the arguments by hand, the program returns with error code 0

    Looks like a bug to me, right?

    kind regards,
    Torsten
  • Hello,
    I would like to add, some argument, why I think that this behavior is a bug (a very small bug, of cause ;) and should be fixed:

    I've started to use JLinkExe in my build environment and there, some steps involve flashing binaries. If one of such steps during a build fails, of cause the entire build fails as we don't won't to ship products where an error occurred during the build process. Think of some kind of automated test, where you build a test program, flash it onto the device and run the tests. You don't want to ship a product, where building the software failed and you don't want to run a test, where the flashing the program failed and you don't want to ship untested software.

    kind regards,
    Torsten
  • Hi Torsten,

    Your first statement is that it runs without errors then you say it produces errors on OSX. Under what conditions did it work?

    You go on to say that you enter arguments by hand and it returns 0. How would an interactive JLink session return 0?

    If the conditions in which it worked were under Windows is it possible that the script has incorrect line separators? "\r\n" rather than "\n"? That problem still creeps in every once and a while.

    Kenny
  • Yes, there is no problem executing the script, but the program that executes the script (JLinkExe) returns a result, that indicates, that there was a problem. Link you are call a function to print 42 on the screen, you see the 42 and the function returns with a error code, that indicates that there was a problem. So there is no error, but the script interpreter (JLinkExe) tells the executing shell (bash on OSx in my case) that there was a problem.

    An interactive JLink session returns 0 if I submit the "quit" command for example:

    C Source Code

    1. > JLinkExe
    2. SEGGER J-Link Commander V4.90b ('?' for help)
    3. J-Link>q
    4. > echo $?
    5. 0


    If I have a script, just containing the 'quit' command, JLinkExe returns with 1:

    C Source Code

    1. > echo q > test.jlink
    2. > JLinkExe test.jlink
    3. SEGGER J-Link Commander V4.90b ('?' for help)
    4. Processing script file...
    5. Script processing completed.
    6. > echo $?
    7. 1
    Display All


    When I want to integrate JLink scripts in higher level build scripts, I need to evaluate the return value of JLinkExe to make sure, I stop on errors, or I have to ignore the return value and loss the possibility to detect errors.
  • I'd like to second this concern.

    It's a bit tougher to write automated tests if the script returns an error condition on exit.

    Right now I have to catch the exception, then process the output to try and figure out if it worked or not.
  • Hi,

    Sorry for the late reply. Very busy days...
    We will have a look into this.
    Indeed, both modes (interactive as well as command line) should behave the same way regarding return values.


    - 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.
  • I've had issues with this as well. It becomes problematic to use scripts for JLinkExe in Makefiles because the return code causes Make to think that the make target failed and it aborts unless you modify the Makefile to ignore errors from the JLinkExe command. However, this misses the case when part of the JLink script actually fails.

    Jeff
  • Hi,

    So far, J-Link Commander does not have defined return values.
    This is something which is already on our internal ToDo-list and planned to be available in the next 8 weeks (depending on the work-flow).


    Best regards
    Erik
    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 - Erik wrote:

    Hi,

    So far, J-Link Commander does not have defined return values.
    This is something which is already on our internal ToDo-list and planned to be available in the next 8 weeks (depending on the work-flow).


    Best regards
    Erik
    Hi there sorry for reviving a 1.5 year old post, but i recently switched from using ST Link to a Flasher ARM and im running into this same issue where the Jlink.Exe returns an error code 1 instead of 0 on correct execution.
    I also could not find an error list on the Flasher's documentation nor in any post on this forum.

    Might i add that even when the script does not correctly run, lets say because the flasher was not even plugged in, it still returns an exit code of 1.

    It would be really awesome to have some sort of feedback from jlink.exe, so my custom software can display a meaningful message to its end users.