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:
...and after that RTT logging flows from telnet port 19021.

Here's a fail case, again with timestamps:
...and after that no RTT logging whatsoever is emitted from telnet port 19021.

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.

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

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:

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

It's part of a much more complex test system so I doubt it will make much sense to you, which is why I have been pulling out the relevant parts, but if you insist then the relevant files are attached.