Pages: 1 [2]
Author Topic: Any SocketCAN gurus around here?  (Read 953 times)
woj
Sr. Member
****

Karma: +38/-1
Offline Offline

Posts: 479


« Reply #15 on: Yesterday at 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
Sr. Member
****

Karma: +38/-1
Offline Offline

Posts: 479


« Reply #16 on: Yesterday at 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: +84/-2
Offline Offline

Posts: 192


« Reply #17 on: Yesterday at 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 Grin
Logged
woj
Sr. Member
****

Karma: +38/-1
Offline Offline

Posts: 479


« Reply #18 on: Yesterday at 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
Sr. Member
****

Karma: +38/-1
Offline Offline

Posts: 479


« Reply #19 on: Yesterday at 12:00:42 PM »

So, you opened a small can of worms Cheesy 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
Hero Member
*****

Karma: +403/-108
Offline Offline

Posts: 4120


« Reply #20 on: Today at 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: +84/-2
Offline Offline

Posts: 192


« Reply #21 on: Today at 04:21:12 AM »

I’m glad you liked the small can of worms  Wink

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  Grin

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.

Code:

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: +84/-0
Offline Offline

Posts: 92


« Reply #22 on: Today at 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
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.018 seconds with 18 queries. (Pretty URLs adds 0.001s, 0q)