Add extra logging to understand which ECU-s are on the bus

[gunicsba]

There are some cases where we have conflicts.
In theory our TC should be the highest prioirty on the bus. We definitely have a bug in the address claim.
Printing the existing ECU-s should help to understand this problem better.

[gunicsba]

Windows Installer_extraLogs.zip

[sujandumaru]

I reviewed the patch, and it looks like this PR now covers more than ECU logging: diagnostics, TC status/version behavior, and some DDOP handling. Are you mainly opening this PR as diagnostic-only work to understand the bus/address-claim problem, or do you want it to also look at the address-claim behavior and become the fix for issue #36?

As a first step, I’m wondering whether #36 should be handled by detecting other Function::TaskController ECUs on the bus and warning the user when our TC cannot claim/keep the TC role.

[gunicsba]

Hello @sujandumaru !

nice to see your interest.

Yes we have a few annoying bugs that I'd like to figure out.

Sometimes we need to reboot the screen / implement so it recognize our TC. When we join the bus late we're not always recognized. Hence I started to move towards TC V4 features (that could happily live with TC V3 implementation).

Other TC on the BUS && address conflict:
We currently fail to "evict" them and I'm trying to find a test case inhouse...
Open-Agriculture/AgIsoStack-plus-plus#685

But some systems doesn't allow to associate priority to TC. I think the above PR might help with some cases.

[sujandumaru]

Thank you @gunicsba for the clarification. That makes sense, and these sound like useful areas to investigate.

I looked through the added logs, and they seem very helpful for understanding the late-join / recognition cases. For the address-conflict side, even though part of it may depend on Open-Agriculture/AgIsoStack-plus-plus#685, I’m wondering if we could add a few more logs to better understand how our TC is claiming/connecting on the bus:

1. Log our own TC NAME and preferred address before address claiming starts.
2. Dump all visible ECUs even when TC address claim fails, before returning false, so we can see whether any control function is already using our preferred TC address.
3. Log the actual address after our TC claims one, so we can tell whether it differs from the initial preferred address.

Would that be useful for narrowing down the address-conflict cases?