BMW i3 CCS/charge port controller

[Jack Bauer]

The only real possible issue that I see from the can logs on the Circontrol unit is I initiate contactor close in energy transfer not precharge. Its hard to see from the one i3 log that I have which comes first : contactor close or transition to energy transfer.

[bitterandreal]

The only real possible issue that I see from the can logs on the Circontrol unit is I initiate contactor close in energy transfer not precharge. Its hard to see from the one i3 log that I have which comes first : contactor close or transition to energy transfer.

I think the best place to get the correct order is a close look at the fast charging sequence diagram.

• ...

• (t4) EVSEStatusCode changes to “Ready” with Cable Check Response <4c>.

• (t5) Start of pre-charge phase with EV sending Pre-Charge Request <5a>, which contains both requested DC current <=2 A (maximum inrush current acc. to CC.5.2) and requested DC voltage.

• (t5 → t6) DC supply adapts DC output voltage to requested value in <5a> while limiting current to maximum value of 2 A (maximum inrush current according to CC.6.1) even if the requested current 0A.

• (t6) DC output voltages reaches requested voltage within tolerances given in IEC 61861-23-1 CD3 chapter 101.2.1.2.

• (t6 → t7) If necessary, EV adapts requested DC voltage with cyclic messages <5a> in order to limit deviation of DC output voltage from EV battery voltage to less than 20 V (cf. Note in CC.5.1). Before the EV closes any contactor the EV stops vehicle internal insulation monitoring.

• (t7) EV closes its disconnecting device after deviation of DC output voltage from EV battery voltage is less than 20 V.

• (t7 → t8) EV sends Power Delivery Request <6a> with ChargeProgress “Start” to enable DC power supply output. EV sets EVReady status “TRUE”. After disabling pre-charge circuit, if any, and switching on its power supply output, DC Supply gives feedback <6b> that it is ready for energy transfer.

• (t8) EV sets DC current request with <7a> to start energy transfer phase.

Below also a document which actually covers Fast and Smart Charging Solutions for Full Size Urban Heavy Duty Applications but since most of the protocols used are similar and it has comparable sequence diagrams with description for normal start up, normal shutdown, DC supply initiated emergency stop and EV initiated emergency stop.
https://assured-project.eu/storage/file ... erence.pdf
Also added a few links about the CCS charging sequences to the wiki...

[Jack Bauer]

Nice. Wiki is starting to fill out. Much appreciated.

[bitterandreal]

Nice. Wiki is starting to fill out. Much appreciated.

You're welcome. Thanks for all your work. I only documented a tiny bit of it...
Could you confirm pinout for the contactors if you have the chance?

[Jack Bauer]

Oh yeah I know this by heart now.
Pin 1 Positive HV contactor Coil +
Pin 2 Negative HV contactor Coil +
Pin 3 Positive HV contactor Coil -
Pin 4 Negative HV contactor Coil -

[CCSknowitall]

The only real possible issue that I see from the can logs on the Circontrol unit is I initiate contactor close in energy transfer not precharge. Its hard to see from the one i3 log that I have which comes first : contactor close or transition to energy transfer.

You should close your contactors at the end of precharge, then send power delivery request. My guess is the LIM handles power delivery request and current demand request messages as soon as you put it in what you call energy transfer state. Depending on the power conversion design, since it can’t sink the requested current, the voltage will start to rise (potentially rapidly) on the DC output causing a fault.

Like a lot of things CCS related, some stations are more sloppy about this than others. Some may take a bit more time to respond to your initial current request messages and so the voltage doesn’t rise and the station might not notice. We’re talking a few hundred milliseconds here, so it’s not too big of a deal in practice.

[Jack Bauer]

Looking through the can on the Circontrol unit today did show up something interesting.

With contactors closed and confirmed closed by the Lim we see 1 amp of current from the evse (evse in ready state) even with 0 amps of current request. Lasts for a few hundred ms before faulting out. Makes me thing the evse was still trying to precharge even when instructed to go to energy transfer. So that makes sense i guess. I'm modifying the state machine now to take more notice of the flags and put lots of time padding in to catch problems.

[CCSknowitall]

Looking through the can on the Circontrol unit today did show up something interesting.

With contactors closed and confirmed closed by the Lim we see 1 amp of current from the evse (evse in ready state) even with 0 amps of current request. Lasts for a few hundred ms before faulting out. Makes me thing the evse was still trying to precharge even when instructed to go to energy transfer. So that makes sense i guess. I'm modifying the state machine now to take more notice of the flags and put lots of time padding in to catch problems.

I suspect you are not respecting the minimum current for the station. It's likely sending a EVSEMinimumCurrentLimit number greater than zero during ChargeParameterDiscoveryRes and CurrentDemandRes. Some converters are not stable at very low or zero amp output. So, they will specify a minimum amperage that they need to operate. If you ask for less, the station will shut down.

In precharge you can specify a few amps (at least EVSEMinimumCurrentLimit number of amps is a good idea) and start there at the beginning of energy transfer. You do not need to start at zero in the current loop (energy transfer) and shouldn't if the EVSEMinimumCurrentLimit is above zero.

One last thing - you're now doing what many automakers do. Good automakers go to nearly every variant of charging station in their market and test with their prototype or pre-production vehicles. There's no golden standard test method or device. Everyone station manufacturer tries to test with every car maker and vice versa. Even though the i3 is well known and doesn't have any major gotchas (that I know about, at least), it seems the LIM is mostly a CAN pass-through to the CCS Homeplug Green PHY. It's up to your software to manage some but not all of the state machine and play nice with the stations. Once a few others have their own LIMs running, they may encounter other issues with other EVSEs not found in your market.

[Jack Bauer]

Funny thing is these Circontrol stations state a min current of 0 and a min voltage of 0. Abb/Ionity say min 50v and 10a. They just ignore anything under 10amps. Likewise the Efcaec say min 50v and min 5a and ignore anything under 5amps. I don't for a minute believe those min volts figures but the currents should be accurate....famous last words I suppose.

Found a way to get 50kw out of the Efcaec QC45 though. Seems real cars ignore the value based limits and bounce of the Ilim and Plim flags!

Ionity don't like me anymore. For some reason I can't get past this "charging will commence when power is available" crap so its probably not liking something I'm transmitting that the others ignore. This is where some CAN LOGS would come in real handy folks but I'm done asking at this point. Big thanks to all the folks who have helped out. No way would it be nearly as advanced without you.

[CCSknowitall]

Yeah this is a tough one without seeing the CCS side. We don't have Circontrol stations in my market so I can't get a capture on my own.

To get wireshark captures, from which I can decode the protocol and see what you are saying, I see two relatively inexpensive options:

1) Sniff the SPI of the Qualcomm chip off of one of the LIMs, and take up davefiddes' offer to convert it to pcap. I believe the Qualcomm chip converts ethernet frames send via SPI to homeplug green phy. I can decode the pcap and see what's going on.
2) Follow this article and purchase one of these dLAN Green PHY evaluation boards (https://www.codico.com/en/dlan-green-ph ... oard-eu-ii) and tap the pilot wire on your side. You'll need an ethernet adapter that supports promiscuous mode, and run wireshark on that interface to get pcaps. The team who wrote the paper do offer a decoder but I haven't used it and I wouldn't need it for me to analyze.

Each path has it's own pain points. The professional tools in this space start at mid four figures and go to six if you want the real fancy stuff. The options above are significantly less money but more of a pain to get set up.

[Jack Bauer]

The spi seems like the best option for me. I'll do some investigation on my spare lim and see if I can find the bus. The ideal thing of course would be to get an i3 for a few hours and drive to all these points and can log how the car deals with them. No one seems to want to do that and I've exhausted all avenues available to me.

[EV_Builder]

Damien; the most important thing is that the DBC is top notch with all you know. If you do that then I will check the code and your statemachine logic.

[mikeselectricstuff]

A while ago I was told (by a supplier of Greenphy modules) that it was not possible to sniff the Greenphy link due to the inbuilt encryption/key exchange stuff, though I have also seen an analyser being sold. Might be that something needs configuring to disable encryption, or that analyser is doing a man-in-the-middle approach perhaps?

[davefiddes]

That QCA7000 HomePlug paperweight/module you got from AliExpress the other week should make it a bit easier to find the SPI pins I would have thought. Assuming it's the same package as the LIM anyway...

Getting a long enough SPI capture will require some thought. The Saleae Logic software is only good for 24 second captures which seems tricky when juggling the CCS charger start process. Sigrok and the PulseView GUI offer huge multi-gigasample captures provided your laptop disk is up to it with the Saleae Logic probe. Details: https://sigrok.org/wiki/Main_Page or install from your Linux distro.

Offer still stands of building an SPI to PCAP converter. Don't know how long it will take. A few days at least. The QCA7000 doesn't seem too obtuse a chip to decode based on the Linux driver.

[davefiddes]

A while ago I was told (by a supplier of Greenphy modules) that it was not possible to sniff the Greenphy link due to the inbuilt encryption/key exchange stuff, though I have also seen an analyser being sold. Might be that something needs configuring to disable encryption, or that analyser is doing a man-in-the-middle approach perhaps?

Shouldn't be a problem if using SPI captures as you're basically grabbing the Ethernet frames as they pass by after the QCA7000 has done it's magic.

The V2GInjector guys (https://sstic.org/media/SSTIC2019/SSTIC ... -dudek.pdf or https://github.com/FlUxIuS/V2GInjector) talk about the impact of HomePlug security and EV charging.

[CCSknowitall]

There’s two layers of encryption-

1) is on the home plug green phy side. There’s a key exchange during SLAC, it should be handled by the QCA7000 internally. I think the Ethernet frames sent over SPI are then packed into home plug frames, which are encoded/“encrypted” with the key. The Ethernet frames themselves on the SPI bus should not be encrypted.
2) is for ISO 15118, the vehicle can optionally ask for TLS encryption during the set up process (SECC discovery protocol) if the station offers it.

If DIN is used, TLS doesn’t happen. I’m pretty sure at least you
‘14 LIM will default to DIN 70121 and won’t ask for TLS so you’ll be in the clear.

[mikeselectricstuff]

That QCA7000 HomePlug paperweight/module you got from AliExpress the other week should make it a bit easier to find the SPI pins I would have thought. Assuming it's the same package as the LIM anyway...

Not an issue since I found the QCA7000 datasheet :
viewtopic.php?f=17&t=1677

[CCSknowitall]

Found the documentation on the QCA 7000 SPI set online:

https://technodocbox.com/91529822-Anima ... tocol.html

Think this is what you need to build an SPI to PCAP converter a bit faster than going through studying the Linux driver. Seems someone already did this!

[davefiddes]

I wrote that sentence having just read the QCA7000 datasheet...doh. It was late.

FWIW I've spent a long time building embedded Linux products so spelunking through Linux kernel drivers is pretty much second nature. Looks easy to get the Ethernet frame data for TX and RX we're looking for. Thankfully I shouldn't need to understand the whole function of the SPI protocol just enough to get at the data.

If it starts using TLS then all bets are off as you say. Looking at the teardown of the LIM it looks like the V850 only has 64KB of RAM. I think that's a bit optimistic to run an embedded TCP/IP stack *and* TLS even if really pared back.

As an aside it's clear that the CCS interface is a threat boundary from a security perspective. Much badness could happen should an EVSE or EV meet an opposite party with hostile intent. Not much of a concern for a DIY vehicle thankfully...and things being less than perfect right now may work to our advantage in understanding the interoperability problems.

[Jack Bauer]

I guess the ball is in my court then:) Good news is the LIM is full of test pads probably for a flying probe ate so finding the signals and a place to tap in might not be too bad. I'll have a look later today.

Edit : for data capture I may be able to get something sexy from Keysight if they have something that could help? Do they do greenphy tools by any chance?

[Jack Bauer]

Sayyyy something like this :
https://www.keysight.com/us/en/assets/7 ... 2-3488.pdf

[Jack Bauer]

Done! Mike's datasheet made it easy.

[Jack Bauer]

Nothing very exciting here on the bench. Next stop ccs stations.

[mikeselectricstuff]

That's surprising - I'd have expected to have seen at least some initialisation at power-up

[davefiddes]

Seems reasonable enough. They're probably bringing up the TCP/IP stack and PowerPlug interface when they initialise for a CCS session. If they start from scratch every time it'll stand a better chance of clearing out any unexpected state and general weirdness from one session to another. Good for power consumption too not having the device running when not being used.