MEB Chargers

[LRBen]

The charger I have working is from a Porsche Cayenne, I think is one of the the MLBevo chargers as I had it working with Mitchy's teensy script originally. Before that though I had to code it with PIWIS in order to get it to listen to any of the canbus commands, this was mostly just switching off every possible option to make it a dumb charger(minus temperature input from the charge socket).
After that it's only 2 or 3 canbus IDs required to start charging.

So saying that I would say your focus should be on getting it coded, however I can't offer any useful advice on exactly how you go about doing that as I have no experience of it with ODIS or VCDS.

[RetroZero]

Thanks @LRBen. I can code everything off with VCDS I think, but I'm hoping to get it working with all (most of) the bells and whistles. I thought a good start was switching the lock actuator and LED for the baby step, but thats not happening yet. So for now, I'm gathering info to understand how to go I'll try Damien's log again....

[RetroZero]

Managed to play back a VCDS log blinking charger LED and it worked. I'll try to hone in and find the ID and bits next.

[uhi22]

Is it possible to share this log?

[RetroZero]

Will do a new capture tonight and gladly share.

[RetroZero]

As promised, here are 3 logs.
I have not tried the lock actuator or charger plug lock myself yet, but used VCDS to operate them.
Hope his helps step in the right direction.

[uhi22]

Code: Select all

File "VW MQB Charger Green LED Blink with VCDS.csv"

References:
- https://de.wikipedia.org/wiki/Unified_Diagnostic_Services explains which service IDs have which meaning.
- https://embetronicx.com/tutorials/automotive/uds-protocol/input-output-control-in-uds-protocol/ sequence chart of UDS input output control

- ID 0x700 says 02 3E 80, this is TesterPresent. The 0x700 is a "broadcast ID" so all ECUs see "a tester is connected".
- The scaling of the time is not clear, normally the TesterPresent is in 2s cycle.
- The charger sends application messages on 0x6C0, 0x594, 0x5FC, 0x5CC.
- The diagnostic communication between the tester and the charger (UDS on ISOTP) uses the CAN IDs 0x744 (request) and 0x7AE (response).
- As precondition to be able to control anything, the tester writes some identification data (tester serial number
and something similar) using the UDS write service (2E) to the DIDs 0xF199 and 0xF198. Each of this leads to a positive response (6E).
- Now comes the interesting part
- Request:  2F 0A 1B 03 FF 00 00 02 is an InputOutputControl, for DID 0A1B, shortTermAdjustment, data FF000002.
- Response: 6F 0A 1B 03 FF 00 00 02 is a positive response for the InputOutControl
- Now a lot of repeated ReadDataByIdentifier (0x22) for DID 0x0100, which is answered always with the value 0xC0. Could be a status.
- Finally request  2F 0A 1B 00 is the InputOutputControl for the same DID as above, returnControlToEcu. Mean this is the end of the shortTermAdjustment.
-         response 6F 0A 1B 00 is the positive response.

File "VW MQB Charger Red LED Blink with VCDS.csv"
The IOControl is slighly different (other value of the last byte)
- 2F 0A 1B 03 FF 00 00 01
- 6F 0A 1B 03 FF 00 00 01
So let's assume that the last byte controls which LED shall blink.

File "Lock_Unlock Charger Plug Type2 VCDS.csv"
- Uses IOControl 2F 80 F5 02 and 2F 80 F5 00
- Means: The locking/unlocking of the connector can be done with IOControl on DID 0x80F5 with value 2 and 0.

[RetroZero]

This is awesome data, thanks @uhi22. It helps me (and other non programming people) to understand UDS protocols and how to remove them from the equation. I have a few more tests I can carry out with VCDS and I'll try them this weekend and post.

[RetroZero]

So the dumb question is....... How to play this back through SavvyCan and hopefully get the LED blinking?
I've got some software set up, now for the difficult part where I am in the dark......coding.

Edit - what I am asking is : is it possible to send data for byte 8 with SavvyCan and activate the LED that way?
Do I need other messages to be sent at the same time?

[RetroZero]

Since the only thing I am capable of at the moment is data capturing, is this sort of capture any good for advancing reverse engineering?
Basically I cleared all CAN frames and then started selecting values in VCDS. There was traffic in SavvyCan, so I imagine there is CAN data related to each value individually as well. If this helps, I could start again and log each value individually. Would these types of logs help us (you boffins) to link a CAN message to an actual value?

[RetroZero]

@uhi22, is it possible to point me in the right direction?. I understood that sending 2F 0A 1B 00 on adress 0x744 'should' get the Green LED to be requested to light up. What am I missing? Do I need to simulate a request as if its from a tester?

[uhi22]

There are two totally different kind of possible communications with the control unit:

1. The "normal", "cyclic" application CAN messages. They have usually CAN IDs below 0x700, and are sent by various control units during the normal car operation.

2. The diagnostic messages, UDS over ISO-TP. This happens only if a diagnostic tester is connected to the car, and the content depends on what the user is doing with the tester. It is intended to support the repair shop, so that they are able to control every light, actuator, whatever, and to read measurements (e.g. voltages or currents), and to read and clear the error memory. The CAN ID 0x700 is the "broadcast" messages, which the tester sends and all connected control units receive it. It is used for the "Tester present" UDS message, which says to the control units "The tester is still connected", and this leads in the control units to keep the current diagnostic session. Each control unit has a certain pair of CAN IDs to talk with the tester. The tester sends a request to the control unit on one CAN ID, and the control unit sends back the diagnostic response on the other CAN ID. The control of a certain light using diagnostic commands usually needs more that just sending one message. A typical example of such an UDS InputOutputControl could need:
- The tester sends a request to enter a specific diagnostic session (e.g. extended session), and the ECU gives a positive response. (not seen in the trace above).
- The tester sends a kind of "authentication" or "Security Access" (not seen in the above traces). This may (shall) prevent replay attacks.
- The tester writes certain identification data (2E F199 and 2E F198 in the discussed trace)
- The tester sends a IOControl with a certain DID, with the command "ShortTermAdjustment" and certain data. This disconnects the light from the application logic, and controls it directly from the diagnostics command.
- The tester sends "tester present" each two seconds, if no other diagnostic commands are ongoing. If no tester communication is ongoing at all, the ECU falls back to "normal mode" after a timeout of some seconds.
- The tester may read some data during the test, e.g. to query the status or measure voltages or currents. E.g. using the service 22 (ReadDataByIdentifier).
- If the tester wants to actively switch the ECU to normal mode, it sends the IOControl with "ReturnControlToEcu" (Example 2F 0A 1B 00). This terminates the control of the light by the tester, and the normal application logic is responsible for the light control.

The sniffing and analysis of the UDS commands is good to get an overview what is possible to control with a diagnostic tester. It helps to check the wiring of the lamps and motors.
On the other hand, the understanding of the UDS commands does not help regarding to the cyclic messages which are needed for communication with other control units. The other control units do not use UDS to control the charger. Only the diagnostic tester uses UDS.

If you plan to do more analysis of the UDS communication, it would be helpful to record a complete session, means to start the recording in SavvyCAN before starting the diagnostic tester.
If you plan to find out the CAN communication which is needed during normal car operation, the analysis of the UDS communication is not of much help.

[RetroZero]

Thanks for the informative response. I thought it was something like you explained. So for finding out ID's of different data, having a VCDS hooked up showing actual values, will not help whilst using savvycan in 'fuzzing mode ', because it's 2 different 'languages' being used?
To move forward, CAN logs from a working vehicle are needed then, because the communications used by VCDS are not that of a working vehicle, which is what we're trying to simulate.
I was trying to use the VCDS as a 'working vehicle ' and playing back ID's to see which values changed.

[uhi22]

Yes, two different "languages". The VCDS talks UDS, the real car environment talks plain CAN.
Yes, CAN logs of a working vehicle are a good starting point. So find out the part number and software version (should be visible in VCDS), and find out in which vehicle versions the charger is used.

[LRBen]

I think trying to get the led and lock working as a first step might be doing the most difficult bit first. The cayenne charger controls the LEDs itself with no input on can. They simply light based on the charger status at the time.
I also never got the charge port lock working properly. It would lock when charging but I never got it to unlock currently. In the end I coded the lock actuator out and removed it.

I would go straight ahead and focus on setting voltage and current. Those are the two parameters that you really need. You should also try to add a dummy load to the charger so you can see when it does work. I used an oven element, obviously be aware of the HVDC when hacking up an oven element to the charger.

[RetroZero]

I assume adjusting the voltage and amps settings is going to be more than simply choosing from the drop down menu in VCDS, plugging in my type 2 charger with an iron element across the HV, and away you go?

[LRBen]

That's pretty much all I send for the Cayenne charger when it is plugged in. A voltage and a current, plus HVK_HVLM_Sollmodus = true, which is the charger activate signal. Not sure if that will translate into VCDS.

[RetroZero]

So if for example I managed to get a CAN log from a working vehicle, how would we go about working out which message is for what value? Since it's not a simple brake switch or LED lamp, you cannot 'see' or hear when a message is valid for a certain command.

[uhi22]

Assume we have a log of a working vehicle, which includes the start of the charging session.
If we are lucky, we could replay this log against a single charger, and the charger would react. Of course before replaying, we removed the messages which are coming from the charger from the log, to avoid collisions.
If we came so far, we now could narrow-down the set of messages. Most likely there are much more messages in the log than the charger really needs. So replay the full set -> charger works.
Filter out message 1 -> check out whether the charger works.
Filter out message 2 -> check out whether the charger works.
and so on.
If we have 30 messages on the CAN, then we have 30 experiments and afterwards we know, which messages are required by the charger.
In these (few) messages, just by looking at them we should see some changes while the charging starts. Maybe comparing the content at different SOCs. This could reveal the intended signals.

[Bigpie]

The logs are here:https://github.com/DomT177/GolfGTE

FWIW, I played around with the GTE charger for a while, despite coding away the lock, it still tried to actuate it and ODIS showed a locking error. I wasn't able to get it to do anything much.

viewtopic.php?p=48161#p48161 has the ID's required when Damien had it doing some charging. There's quite a few interlocks on these chargers.

[RetroZero]

I'll have a go at playing it back through savvycan and see what I might find to be similar in the MQB DBC file @mitchy linked earlier.
Just a thought, if we were able to duplicate CAN identicle messages that the charger resuires, wouldn't the VCDS 'translate' this into UDS and I would see them changing via actual values?
When I check engine temp or rpm on my Golf 6, this is what happens no?

[uhi22]

The VCDS does not translate the raw CAN messages. The process is like this:
- For example, SavvyCAN (or the real car) sends a CAN message with the intended charge current. The sender would be the BMS in this case. Let's say this is byte 1 of the CAN message with ID 345 (just as an example).
- The charger receives the CAN message 345, takes the byte 1 and now knows: The BMS wants e.g. 9 amperes.
- The charger *may* have the possibilty to read the intended charge current via an UDS service. Let's say there is a diagnostic ID 0x5678 for this purpose.
- The user of the VCDS selects to read some data.
- The VCDS sends an UDS request to the charger, ReadDataByIdentifier for DID 0x5678. Technically, this is CAN ID 0x744 with the data 03 22 56 78.
- The charger knows this service, and that's why it sends a positive response with the data. Technically, this is CAN ID 0x7AE with data 04 62 56 78 09.
- The VCDS receives this, and interprets the 09 as "9 amperes". (This scaling could be different, is just an example.)

But, this is just a dream. It is not clear, which measurement values does the charger provide via ReadDataByIdentifier. Ideally, the VCDS would offer a pick list or menu or something like this, where you can select what you want to read. This list of those measurement values could be helpful for analysis.

[Bigpie]

VCDS is useful because it'll report the state the charger is in but it's extremely unlikely the VCDS UDS messages will cause it to charge.

So you're going to want to connect VCDS and read an error states/codes and address them, either by physical signals or can messages. Once it's happy just powered on, you can move on to something else, like plugging in an EVSE and repeat, once it's happy with it just plugged in, try sending messages to charge etc.

[RetroZero]

The VCDS does have a list. There's about 30 or more values to choose from. There's a screen print out in a previous post of mine of some of them.
@Bigpie, I'll see what I come up with in terms of error codes and how to adress them.. I'll play back different logs and see if anything comes up on the VCDS whilst selecting different values.

[RetroZero]

Attempt to find Unlock button on charger flap ID
First checked Actual Value in VCDS and confirmed value changes according to button pressed or not.
No VCDS connected (after I confirmed that the correct message was being received by the charger)
Cleared all Frames in SavvyCan and pressed the button 5 times at 1 second interval.
Then using Sniffing, I replayed the saved data, and I tried to isolate the changing bits. There are 4 ID's that are active, but non that seem to relate to me pressing the Unlock Button 5 times.
I'm looking for "what I am not doing correctly" and not a spooon fed solution. Thanks in advance

For info, I did the same with a type 2 charger plug, but there are even more messages, as the actuator lock, the Control Pilot and Proximity Pilot are also activated, so thought to start with single command. Having said that, when pressing the unlock button, a command is sent to unlock the actuator.

Edit - Charger Type 2 plugged in halfway for Proximity Pilot signal attached as well.