Hi guys, I have a question about the Remote API. We have a Jenkins pipeline running multiple software tests, mostly triggered overnight. In these test, we often make use of Trace32 to set breakpoints. check variable values and so on. For some time already, we observed that seemingly suddenly, without a real explanation, we cannot connect the Remote API driver to the running Trace32 process - "T32_Init" returns -1, no matter what we try (i.e. running "T32_Exit", re-starting the Trace32 process, power-resetting the debugger). Interestingly, while the test process is not able to connect the driver, we can run "t32rem" and it is able to connect and run commands. Also starting another test process where we use the Remote API in the same way does work. Only the current test process is not able to connect. It has to be mentioned though, that the test process is running for hours, executing multiple thousands of test, where the driver is triggered a vast amount of times and is initialised and exited around 20 - 40 times. This issue appears very sporadically, it is mostly not reproducible except of executing the nightly test - most of the time it is appears at seemingly random point - however, more often than not it happens rather at the end of the Jenkins pipeline (after the driver was triggered a couple times already). I have tried to investigate the issue but I could not find the reason for that, except that when triggering the "T32_Init" around 18 times right after each other, it starts to return -1 until "T32_Exit" is run (the same happens even when "T32_Init" is followed by "T32_Exit"). I would appreciate if you guys could help me out here - is there any way to get more information on the exact error message? Is there a way to reset the drivers or similar? Thank you!

Did you check that the previous test was run completely (I mean until T32_Exit is called)?

Did you try running T32_Exit before T32_Init in all your test? (please try this if it is not the case)

Otherwise, did you check that TRACE32 remained stable and responsive? (I assume it is as you said that you can connect to the same instance using t32rem)

Hi! Yes, T32_Exit is always called beforehand, and no Trace is not crashed and I am actually connecting to the same instance with t32rem (which is possible, because inside the tests the connection is refused).

As you are able to connect using t32rem, the problem is not in TRACE32.

Are you sure that the port number and node name is still correct in your test?