Tester present during $7F $78 pending response

[ryedwards]

Firstly, thank you for creating this great library! It is very extensible and has been a great help in many of my projects.

One item I was hoping for help with or if there could be a recommended solution. We are currently using the library to manage a UDS reflash of an ECU. One such ECU takes a long time (~20 sec) to perform a memory erase ($31 $01 $FF $00 $XX). During this delay the module responds with a periodic $7F $78. The module times out with a $7F $72 if it does not receive a tester present in this window.

I am currently using a thread with semaphores around the other diagnostic requests to send tester present every second throughout the reflash process. The issue is that for a $7F $78 the library is blocked during this state and the semaphore around the mode $31 prevents the tester present.

Is there something built into the library that I'm missing that can support this use case? If not, could a feature be added for a callback of some type during a $7F $78 to indicate to the application that it's in this blocked state and allow for the transmission of a tester present.

Any help would be appreciated.

[pylessard]

Does your device expect to receive more than one requests at the time on the same channel? Like this:

Req1
Req2
Resp2
Resp1

Req1 being memory erase and req2 tester present?

Does your device send a response on tester present? Do you have control over the firmware of the device?

[ryedwards]

Does your device send a response on tester present? Do you have control over the firmware of the device?

No - I am sending $3E $80 so it does not respond. If would only respond on a error in which case we have bigger problems :)

The other legacy tool we use for this seems to send tester present immediately after the $78. I need to pour through their source but it's in C++ and is crazy abstracted. So far I think they are just sending the $3E $80 blindly to the J2534 driver.

[pylessard]

I could probably accomodate something. But there might be some weird edge cases related to timing. You need to make sure the devices doesn't respond.

Will come back to you

[ryedwards]

I did get something "working" by editing the Client class and adding a manual $3E $80 send in the section prior to the response code checks. A simple "if" statement that checked the return code for $78 and issues a .send(). Not great, but it allowed me to test the rest of the code.

[pylessard]

couldn't you simply have another client object that handles the TesterPresent periodically? That could also get you rid of the semaphore

[ryedwards]

I was able to get that to work with iso-tp using a tester txid and functional request (I didn't need the semaphore with this). The issue was with doipclient. It was NOT happy with multiple clients. Need to chat with Jacob on that one - different topic :)

[pylessard]

Right, check #250. @kirya-dev made something about issues with non-thread safe .DLL

I've been thinking about your issue. It falls into the category of issues that would get solved with a per-service listener architecture. Best I could do with the actual single-request/single-response architecture is offer a callback on NRC78. Each time the server request to wait, I could call that callback before going back to waiting on a message. Would leave you the opportunity to send your request

You could also make your own connection that inherits another and handle the tester present there, but that would be hacky, putting app level stuff in the lower layer.

Would the callback be good for you?

[ryedwards]

I was thinking along the same lines. An addition to the config that defaults to None. User can add a function as needed into the config that will be called from the $7F $78 check in send_request().

I like the idea - provides for the most flexibility and puts the implementation on the user.

[pylessard]

Do you want to try add_callback_when_receive_nrc78 ?
https://github.com/pylessard/python-udsoncan/tree/add_callback_when_receive_nrc78

[pylessard]

I added the feature. Part of v1.24.0