J-Link for RTT logging sometimes stalls when run after download

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

    • J-Link for RTT logging sometimes stalls when run after download

      Further to [SOLVED] J-Link freeze in multiply parallel environment, having resolved that problem in a multiply parallel environment we seem to be left with a residual issue, which is that on some occasions (around the 1 in 10 times mark again) a J-Link session opened for RTT logging fails to emit any logging whatsoever from the target.

      On these occasions it seems that J-Link, or whatever underlies it, is confused about the process it is serving.

      In detail: we run Nordic nrfjprog to download to the NRF52 platform (details of the command-line below). This is driven from a Python script as a sub-process, non-shell, as described in the post concerning the previous problem, and runs perfectly normally, exiting all by itself having completed the download, no forced exit or anything of that nature.

      We then start J-Link to do RTT logging and, in the fail case, rather than indicating that the process is jlink.exe, J-Link prints out that the process is nrfjprog.exe, which terminated a second or two earlier. Find below a success case and a fail case for comparison.

      Do you have any suggestions as to how we might prevent this confusion from occurring? It is worth remembering that, as indicated, we are running multiple of these in parallel, our assumption being that by including the debugger serial number in the command-line that the processes are utterly separate. Is that a safe assumption or might there be "danger times" when that is not true? If so, what such situations should we avoid?

      Here's a success case with timestamps shown on the left:

      Source Code

      1. 2020-11-23_10:08:18 nrfjprog -f nrf52 --program u_pca10056.hex --chiperase --verify -r -s 683253856
      2. 2020-11-23_10:08:21 Parsing hex file.
      3. 2020-11-23_10:08:22 Erasing user available code and UICR flash areas.
      4. 2020-11-23_10:08:23 Applying system reset.
      5. 2020-11-23_10:08:24 Checking that the area to write is not protected.
      6. 2020-11-23_10:08:24 Programming device.
      7. 2020-11-23_10:08:33 Verifying programming.
      8. 2020-11-23_10:08:42 Verified OK.
      9. 2020-11-23_10:08:42 Applying system reset.
      10. 2020-11-23_10:08:43 Run.
      11. 2020-11-23_10:08:45 [nrfjprog, pid 3840 ended with return value 0].
      12. 2020-11-23_10:08:46 jlink.exe -Device NRF52840_XXAA -If SWD -Speed 4000 -Autoconnect 1 -ExitOnError 1 -RTTTelnetPort 19021 -USB 683253856...
      13. 2020-11-23_10:08:49 SEGGER J-Link V6.86g - Real time terminal output
      14. 2020-11-23_10:08:49 J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 17 2020 14:43:00 V1.0, SN=683253856
      15. 2020-11-23_10:08:49 Process: jlink.exe
      Display All
      ...and after that RTT logging flows from telnet port 19021.

      Here's a fail case, again with timestamps:

      Source Code

      1. 2020-11-23_14:33:57 nrfjprog -f nrf52 --program u_pca10056.hex --chiperase --verify -r -s 683253856
      2. 2020-11-23_14:34:00 Parsing hex file.
      3. 2020-11-23_14:34:01 Erasing user available code and UICR flash areas.
      4. 2020-11-23_14:34:01 Applying system reset.
      5. 2020-11-23_14:34:02 Checking that the area to write is not protected.
      6. 2020-11-23_14:34:02 Programming device.
      7. 2020-11-23_14:34:11 Verifying programming.
      8. 2020-11-23_14:34:20 Verified OK.
      9. 2020-11-23_14:34:20 Applying system reset.
      10. 2020-11-23_14:34:21 Run.
      11. 2020-11-23_14:34:23 [nrfjprog, pid 9544 ended with return value 0].
      12. 2020-11-23_14:34:24 jlink.exe -Device NRF52840_XXAA -If SWD -Speed 4000 -Autoconnect 1 -ExitOnError 1 -RTTTelnetPort 19021 -USB 683253856...
      13. 2020-11-23_14:34:27 SEGGER J-Link V6.86g - Real time terminal output
      14. 2020-11-23_14:34:27 J-Link OB-K22-NordicSemi compiled Jan 21 2020 17:33:01 V1.0, SN=960115898
      15. 2020-11-23_14:34:27 Process: nrfjprog.exe <-- in the fail case J-Link always prints that the process is nrfjprog.exe and not jlink.exe
      Display All
      ...and after that no RTT logging whatsoever is emitted from telnet port 19021.
    • Only one process can listen on a port.
      If you start nrfjprog.exe first, it gets the 19020 port, so it will be the default instance RTT Logger connects to. You either need to add a delay between exiting nrfjprog.exe and starting JLink.exe (otherwise you have a race condition if JLink.exe gets the port or not) oooooooooooor simply do the download from JLink.exe as well (which will be faster anyhow...)

      Neither the post you referenced, nor the issue in this thread are J-Link problems. J-Link does not confuse anyhing. It‘s a setup / usage error.


      BR
      Alex
    • Thanks for your swift response.

      The port numbers we use are distinct for each parallel case, of course.

      No port number is specified at all to nrfjprog: the download process needs/takes no Telnet port, as far as I'm aware: please tell me if I'm wrong.

      Could you explain what the line "Process: xxx" printed by J-Link means? Why is any other process involved at all, all we have asked for is for the target serial number in question to have its RTT output sent to a Telnet port that we specify. The only thing involved with this, as far as we are aware, is J-Link itself as it's the only thing we've invoked to do it.
    • Can you please describe what exactly you are doing?
      • Starting nrfjprog.exe to program the device
      • Exit nrfjprog.exe
      • Starting jlink.exe to do what?
      How do you get the RTT data? Do you connect directly via TCP/IP to a specific port?
      Do you instruct jlink.exe to start RTT etc.? If yes, what exact commands do you pass to jlink.exe?
      The easiest would probably to get your Python script to get an idea what you are doing.

      Right now, it is not really clear what is involved and what steps *exactly* are performed in which order.
      The Python script would clarify this.
    • Yes, that's correct. nrfjprog is started with the command line:

      nrfjprog -f nrf52 --program nrf52840_xxaa.hex --chiperase --verify -r -s <serial number here>

      The Python code that does this is

      Source Code

      1. subprocess.Popen(<the command line above>,
      2. stdout=subprocess.PIPE,
      3. stderr=subprocess.STDOUT)
      The download is allowed to complete successfully, the Python sub-process exits all by itself with return value 0.

      J-Link is then started to obtain RTT logging from the same board with the command line:

      jlink.exe -Device NRF52840_XXAA -If SWD -Speed 4000 -Autoconnect 1 -ExitOnError 1 -RTTTelnetPort <Telnet port> -USB <serial number here>

      The Python code that does this is:

      Source Code

      1. subprocess.Popen(<the command line above>,
      2. stdout=subprocess.PIPE,
      3. stderr=subprocess.STDOUT,
      4. stdin=subprocess.PIPE)
      [The difference in this case being that, as you requested, we can use stdin to send the string "exit\n" to J-Link when we wish to stop it]

      In all cases the serial number is appropriate to one of the three NRF52 boards we have on this test system. The Telnet port numbering starts at 19021 and is unique to each board (so 19021, 19022 and 19023).

      This sequence of operations is started and allowed to run asynchronously and in parallel on the three boards; since there is no connection between them they should not affect each other.
    • Hi,

      Can you please provide the full Python code, command files etc. you are using to get RTT data from JLink.exe?

      If this is an issue on our side, we need some more information about the exact setup and what exactly should happen, according to the code.