Infinite retry implementation/interpretation

[tttech-miori]

A command timeout that the standard mandates to be indefinitely retry blocks completely the execution of the software flow. E.g.: Master().connect() on a broken bus or shutdown ECU indefinitely blocks and termination of process is required.

Even though the standard says "Indefinite / Infinte Retry" I would prefer to have a configurable number of times that this is retried (even 0) and after that the command invocation shall just raise an exeption. The user of the Master class can then decide externally, based on the exception, whether or not to retry. I think that is the spirit of the "repeat infinte times" XCP protocol standard statement i.e. if it doesn't connect, of course you need to retry until it does.

Specific use case: if the ECU under test is unexpectedly behaving there is no way to automatically get out of the infinte retry.

1. What do you think about my observation?
2. Is there already a way to "bypass"/"configure" that indefinite retry without too much runtime patching?

Thank you

[tttech-miori]

version 0.18.48

[tttech-miori]

Probably fixed here: https://github.com/christoph2/pyxcp/pull/120 To be tested.

[tttech-miori]

hmm I tried to upgrade the pip package to 0.18.58 but apparently the problem is not fixed. EDIT: by reading my original report again, I believe the current implementation is actually fine towards the specification BUT I still think we need to somehow provide a user-configurable behavior for the connect case. Use cases I see:

• automatic testing: if a ECU fails or the connection fails, then we want to actually actively fail the test without a more global timeout.
• ECU scanners: when scanning a bus, it may happen that ECUs are not responding. We need to ignore that
• GUI tool failing to connect shall not block forever