|
woj
|
 |
« Reply #15 on: June 11, 2021, 12:42:34 AM »
|
|
|
Can you set some hardware receive filters in your CAN controller to avoid overflowing its buffers if the CAN to SPI to software path is delayed?
Can you try to shut up the other modules during the flash so they don't give you unwanted traffic?
I missed that one. Yes, I could and it was one of my ideas. But since I want to have full SocketCAN compatibility and universal firmware and gs_usb does not support hardware filters, that was no option. As for shutting the other modules - that's precisely why I have developed all this software, so that I can go to the car, plug in the cable, press ENTER and have the ECU updated for the next experiment in 1 minute, not to bother with unplugging things, taking fuses out, and what not. |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #16 on: June 11, 2021, 12:45:37 AM »
|
|
|
You could just use J2534...
*ducks for cover*
You are not the kind of a person that ducks for cover, you won't fool us... ;P J2534 was on my to investigate list, I even found some open source software for it at some point, only I could not get good info on which of the cheap clones would perform good for a safe buy, got this gs_usb stuff working in the meantime, so it was forgotten. |
|
|
|
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
 Offline
Posts: 192
|
|
« Reply #17 on: June 11, 2021, 08:18:41 AM »
|
|
|
I missed that one. Yes, I could and it was one of my ideas. But since I want to have full SocketCAN compatibility and universal firmware and gs_usb does not support hardware filters, that was no option.
I don’t know your particular vehicle setup (I don’t think it was VAG) but typically if you are plugging into the external OBD connector, then that hangs off the CAN gateway which is already filtering out all the internal broadcasts and only allowing diagnostic traffic to traverse? If there indeed is a vehicle CAN gateway in your scenario minimising broadcasts and securing the inside comms, then the candump workaround is quite strange indeed. As for shutting the other modules - that's precisely why I have developed all this software, so that I can go to the car, plug in the cable, press ENTER and have the ECU updated for the next experiment in 1 minute, not to bother with unplugging things, taking fuses out, and what not.
I think he may have meant UDS command $28 CommunicationControl “Mute”, to politely ask modules to stop broadcasting. Not actually pulling out fuses or physical interventions. *ducks for cover*
Hahaha, you are not fooling us  |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #18 on: June 11, 2021, 08:59:04 AM »
|
|
|
It's a Fiat, ME7.9.10. The mute command is something new to me, I have to check it out, that would be ideal. Technically it is still KWP2000, not yet UDS, though I know they are very similar. I knew about reset / restart that I find also very useful.
BTW, thank all contributing, I again learned a lot just from chatting about a silly problem I got.
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #19 on: June 11, 2021, 12:00:42 PM »
|
|
|
So, you opened a small can of worms  Surely there is a mute KWP2000 command, and it works for the Body, ABS, EPS, and engine ECUs. There is one more module on the high speed bus to which I cannot open a successful diag session (I still have to check a couple of ECU ids, perhaps I missed it), according to my service manual that would be the tilt/yawn module, and the messages (also quite dense) from that one remain on the bus. It also works for only 5 seconds so I will have to be doing this periodically when flashing, and periodic tester present to all involved ECUs too. Not an immediate thing to try though, need to do a little bit of coding for this. The downside of this is that I get even a larger and more beautiful X-mass tree of DTCs in all modules, 3 on average in each, and also the Body/Dash ECU is very aggressive electrically on opening the diagnostic session, including turning on the headlights for a second or two. That is not a show-stopper of course, I have full DTC cleaning implemented in my flasher for some time now, just annoying. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #20 on: June 12, 2021, 12:41:15 AM »
|
|
|
You are not the kind of a person that ducks for cover, you won't fool us... ;P
J2534 was on my to investigate list, I even found some open source software for it at some point, only I could not get good info on which of the cheap clones would perform good for a safe buy, got this gs_usb stuff working in the meantime, so it was forgotten.
J2534 is a combination of hardware, driver and Windows DLL provided by the author of the tool. So in many cases it works very well because the manufacturer has control of the entire process. It just stores the DLL location under a certain registry key, which you enumerate in your tool to get the device list, and after that you use a standardized API to access it. Windows only though of course. |
|
|
|
|
Logged
|
|
|
|
Basano
Full Member
Karma: +90/-3
Offline
Posts: 192
|
|
« Reply #21 on: June 12, 2021, 04:21:12 AM »
|
|
|
I’m glad you liked the small can of worms  But this got me thinking a bit and the discussion is quite interesting anyway. I looked at a handful of candump logs, old and new, of various tools when they do a flash. Yes, they send the mute command $28, but only to the target and NOT to everything else? So how does that help? What’s the point of muting the target if it’s going to be quiet anyway as soon as you descend into the bootloader? And all those other nodes will keep chattering away on the bus. So this is a bigger can of worms Or will they? And then I remembered my OSEK Network Management. You have your physical ECU’s strung out on the bus, but logically there is a Network Management Ring Topology with a token being passed around the circle. The token contains various entries like previous station ID, next station ID, bus status (e.g. starting up, shutting down) and there are various operations like join the bus, leave the bus, elect a new master. A lot of these CAN nodes have permanent power (terminal 30 & 30a) and rely upon this OSEK network management to know when to switch on and when go dormant again. So I’m speculating now that by muting only the engine ECU, that in turn has a knock-on effect via OSEK Network Management on the other ECU’s and they may become dormant? This is purely speculation, I don’t have logs to be more conclusive. But it could explain why there are not multiple simultaneous diagnostic sessions open to each module all at the same time and all broadcasting a repetitive mute… Here is some more details on the Network Management albeit VAG specific. I took it off the internet many years ago, but sadly I can’t find the original page again now to give the author full credit. Whoever you are, thank you.
The cluster will remain awake and it will keep the heater, the radio/navigation, bluetooth modules awake if one of the devices in the ring do not send the command to the bus indicating it is ready to sleep.
The sleep command is:
4xx 6 yy zz 00 00 00 00
xx being the module ready for sleep.
2B is the cluster
34 is the heater
39 is the radio
3A is bluetooth
yy contains the ID minus 420 of the module next in the ring.
So if the bluetooth module was going to sleep you would see 0B because the next device is the cluster.
19 if the heater sent the message
0B if the bluetooth sent the message
zz contains the status messages
11 for sleep
01 for normal
02 if the ring is being rebuilt
If you log then take the key out you will see activity for a few seconds then you will see the sleep messages then the bus will go silent.
If you sit in the car while logging with the key out the bus will be silent.
If you turn the key on you will see the devices start to logon.
The devices will announce an intent to login and its own ID minus 420
You will see the cluster say:
42B 6 0B 02 xx xx xx xx
0B its own ID
02 to rebuild the ring
Then you will see the radio say:
439 6 19 02 80 xx xx xx
19 its own ID
02 rebuild the ring
80 request to login
At this point the ring will only have 2 devices so you will see these messages repeating:
42B 6 19 01 xx xx xx xx (19 indicating the next device in the ring, 01 for normal)
439 6 0B 01 xx xx xx xx (0B indicating the next device, in this case the cluster, 01 for normal)
Now the heater logs in:
434 6 14 02 80 xx xx xx
14 own ID
02 rebuild
80 login.
Now we see:
42B 6 14 01 xx xx xx xx (14 indicating the next device in the ring, 01 for normal)
434 6 19 01 xx xx xx xx (19 indicating the next device in the ring, 01 for normal)
439 6 0B 01 xx xx xx xx (0B indicating the next device, 01 for normal)
Notice how the first byte changes after another device logs in.
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
Offline
Posts: 195
|
|
« Reply #22 on: June 12, 2021, 01:04:21 PM »
|
|
|
J2534 is a combination of hardware, driver and Windows DLL provided by the author of the tool.
So in many cases it works very well because the manufacturer has control of the entire process.
It just stores the DLL location under a certain registry key, which you enumerate in your tool to get the device list, and after that you use a standardized API to access it.
Windows only though of course.
The other reason why J2534 works really well is that ISO15765 / ISO-TP is part of the API layer standard. Although it is not _strictly_ required to do so by the standard, most tools implement the timing sensitive ISO15765 flowcontrol messages and framing inside of the firmware at the end of the USB dumpster fire. So, the USB part becomes much less timing sensitive and much less noisy in terms of back-and-forth, which paints over bad USB drivers pretty nicely. That is, instead of sending hundreds of framed packets (and needing to wait between to see if a timing change is in the mix), with most J2534 devices, to send a 4k TransferData command, the DLL is just sending 4k down a bulk endpoint and the device does the rest. At least OpenPort and Panda work this way and I would be shocked if other vendors don't implement with the same strategy. This makes OpenPort hardware a good choice even with massive perversions like re-implementing the J2534 interface on Linux: https://github.com/NikolaKozina/j2534/blob/master/j2534.c . |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #23 on: June 13, 2021, 12:34:33 PM »
|
|
|
That would be the piece of software I mentioned I found at some point when considering J2534. Something came up to be done on the house, so any car dev stuff will have to wait for now. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #24 on: June 14, 2021, 08:29:05 AM »
|
|
|
At least OpenPort and Panda work this way and I would be shocked if other vendors don't implement with the same strategy. Say hello to PeaK PCAN. |
|
|
|
|
Logged
|
|
|
|
jcsbanks
Full Member
Karma: +19/-3
Offline
Posts: 146
|
|
« Reply #25 on: June 14, 2021, 10:20:16 AM »
|
|
|
Although they are a bit physically fragile on the USB connector according to my colleague who uses them a lot in his other business, OpenPort 2.0 works well for the price unless you have a need for your own hardware is a good choice for most and will save you much time in debugging boring stuff and allow you to get onto the interesting stuff. I got mine after a Kvaser J2534 tool failed to adjust STMIN when asked and could not complete a flash through the frame dropping VAG gateways, even though the ECU advertises STMIN of 0 and does it on the bench. Bug reported to Kvaser and several months later they said they'd fixed it. But the Kvaser is just so convenient and easy for CAN bus analysis. Some criticise the J2534 spec for being too vague on many details and causing compatibility issues. For its age, J2534 04.04 is not bad as long as you are not allergic to Windows and many alternatives don't perform like a proper J2534 device should.
|
|
|
|
|
Logged
|
|
|
|
|
