’Almost always’ means that we have four X20CP0484-1 and I am able to activate debugger time to time with only one X20CP0484-1.
To compare successful and unsuccessful connections to the debugger, I created screenshots of the communication between the PC and PLC from the Wireshark program.
Unsuccessful debugger activation ended by mentioned error popup “Debugger could not be started, try to restart the debugger“ after approx. 8 - 10sec.
and there is no ‘gdb’ TCP packet(port 2323) in the communication so according that it seems communication with PLC gdb server has not even been initiated from AS, there is only communication on port 11169 :
Some additional information, although I don’t know if it’s related to this problem.
I thought the communication of AS with PLC debugger(gdb) is made only through TCP sockets on port 2323 but there is some other debugger ‘handshake‘ before it on standard port 11169 and when error popup “Debugger could not be started, try to restart the debugger“ is reported then that ‘handshake‘ socket includes some internal data with “Error” and “OtherClient“.
Hi @Marek_Hluchnik, I appreciate your effort. But I think it would be better to get in touch with local B&R support, provide them all your Wireshark traces and your findings. They can (together with the R&D team) analyze it. Still keeping this discussion open, in case someone has already investigated.
Hi Marek
The “OtherClient = 0.0.0.0” is a bit unfortunate because it doesn’t tell us which peer is holding the lock. However, it still strongly suggests the debugging service is already occupied by an existing session (or a stale lock).
As a quick isolation test, I would try a direct PC↔PLC connection, and reboot both the PC and the PLC. If the debugger then starts reliably, the issue is likely related to the network path or a lingering client/session.
