Connect/Attach to existing session about pylink

[bernardfitch]

Hi @stawiski, I quite often want to call pylink API functions without first having to call connect() - I realise that this is only half of your requirement - but thought my solution might still help you.

I've only had to make very minor changes to pylink in order to allow a 'connection' to be faked. Essentially, all I've done is relax the test for a connection having been made in the open_required() and connect_required() decorators, e.g.:

elif not self.connected():

allowing the tests to pass either if we truly are connected or if a new 'connection faked' member variable is set, e.g.:

elif not (self.connected() or self._connection_faked):

I intialise the new member variable to False in __init__() and have added a fake_connection() method to allow it to be set. By default the module behaves as originally intended, however, if you call the new fake_connection() method the decorators allow you to call the decorated API calls even if no explicit call to connect() has been made.

I use this to allow me to implement the precise (bit-level) SWD connect sequence myself in situations where I want more control than is offered by the jlink DLL, but it can also be used in situations where another party/process has already initiated a connection.

I initially thought of altering the connect() or connected() methods, however, decided that leaving these methods true to the original concept of a connection makes the change both simpler to implement (as the other methods are called in many placed) and keeps the change in behaviour more transparent (as any 'faked' connection is explicit).

@hkpeprah - do you think that the changes I have described would be accepted if I made a pull request? I would far rather be using a real version of plink than my hacked one and I'm sure other people would find the functionality useful.

Andrew ;)

PS. Apologies if I should really have started a new ticket - but I thought this was quite relevant to your question @stawiski

[hkpeprah]

It seems like this is when you already have an active session. You could spawn multiple threads/processes and use the same pylink object across them, but say having GDB running and trying to run RTT in PyLink at the same time is not something we currently support.

[stawiski]

@hkpeprah Thanks for your reply. Yeah i noticed there's no API for this in PyLink. I also couldn't find anything in SEGGER documentation. Too bad!

[hkpeprah]

So we do have an open() and an open_tunnel(); the latter created to connect over the tunnel. I would support adding a connect variant method (i.e. a new connect method) that connects to an already initiated connection provided we can implement some check to ensure it actually succeeds. In that case, we can override the .connected() method to check that existing connection as well if a connection was made in that way.

[bernardfitch]

@hkpeprah Thanks for your reply (and sorry about the speed of this follow up!)

I appreciate your suggested approach (adding a variant connect() method and making sure we can test whether calling it has been successful), however, I don't think that the 'testing for success' part is possible (or at least I don't know of a way of doing it). Let me try to explain from my perspective:

Whilst I sometimes use this 'faked connection' technique when interacting with a target device that some other agent has already established a debugger connection with via the JLink DLL (e.g. the use case @stawiski describes), I often use it when I want to have complete control over the SWD traffic exchanged with a target device. In such cases I use it together with the lowest level SWD functions (e.g. swd_write()) to give cycle-accurate control over the SWD bus. I could imagine that in the @stawiski use case there might be some way you could test the 'connected' state of the debug probe (e.g. even using a relatively null operation such as reading DP.DPIDR) but in my normal 'complete' control case there is not. When I call fake_connection(), I'm doing so at a point where I'm not expecting there to be a connection. After making the call I script the connection process (line reset, read DP.DPIDR, etc) using calls such as swd_write() that are decorated with connection_required.

In preparation to make a pull request, I've cloned the current version of your repo and added my proposed functionality (along with unit tests). Does it make sense for me to submit this as a pull request and then continue this discussion about whether to add the functionality (and whether to do it in the way I propose) in the pull request ticket/thread?

In my cloned repo I've also added a swd_read() method that wraps the JLINK_SWD_GetData() function. This function allows fetching of less that 8 bits from the read buffer (which I found necessary in order to fetch non-byte related things like a group of 3 ACK bits).

Thanks again for pylink-square. I use it a lot - but want to be using a completely official version ;)

[hkpeprah]

@bernardfitch That sounds good to me. We can continue the discussion in the PR. I think my main concern is ensuring that the the connection type (fake vs. real) are abstracted as much as possible.

[bernardfitch]

@hkpeprah Would you rather I submit two very small (but clearly targeted pull requests - one for the additional DLL API call wrapper and a second for the 'fake connection' changes) or a single pull request including both. On reflection, two separate requests seems cleaner to me, but I'm happy to go with a single pull request if that would be less work for you. If you have a strong preference then let me know, otherwise I'll probably go ahead with two (starting with the additional API function wrapper).

[hkpeprah]

I think two PRs would be good, the SWD one should be fairly straightforward to merge without much discussion.