BMW i3 CCS/charge port controller

[muehlpower]

Wiki:



In May2021, Damien spoofed the LIM's expected charge port lock behaviour via a pair of resistors and a bistable relay:

According to my documents, pin 3 is GND, 11,12,13 are NC, 15 is Charge Enable, corresponding to 3B4 bit 21. The return line for the locking signal is on pin 5, not on GND. The welding test only works if pin 5 on the 12-pin connchtor has 1.4V. This signals 0V DC at the charge port! And of course the DC contactor ports must be 16 ohms!

[tom91]

he welding test only works if pin 5 on the 12-pin connchtor has 1.4V. This signals 0V DC at the charge port! And of course the DC contactor ports must be 16 ohms!

Thanks for that nugget of info. Will get on to this, once there is a reliable way of having these things occur will update the Wiki.
Are there any other requirements for the Weldtest to begin? What state /voltage should pin 12 on the 12pin be? (Cover feedback)

I currently have a jank rigged way of putting the LIM into AC charge mode on my bench. Got a cheap chinese lock actuator wired back ward to put a 1K over the 10K for cable lock position feedback.

[muehlpower]

he welding test only works if pin 5 on the 12-pin connchtor has 1.4V. This signals 0V DC at the charge port! And of course the DC contactor ports must be 16 ohms!

Thanks for that nugget of info. Will get on to this, once there is a reliable way of having these things occur will update the Wiki.
Are there any other requirements for the Weldtest to begin? What state /voltage should pin 12 on the 12pin be? (Cover feedback)

I currently have a jank rigged way of putting the LIM into AC charge mode on my bench. Got a cheap chinese lock actuator wired back ward to put a 1K over the 10K for cable lock position feedback.

I close the flap, switch on the ignition and lock the flap. pin 12 open = closed flap/ pin 12 GND = open flap. You can see the flap status on 272h bit 16. 0 = closed, 1 = open

[tom91]

I close the flap, switch on the ignition and lock the flap. pin 12 open = closed flap/ pin 12 GND = open flap. You can see the flap status on 272h bit 16. 0 = closed, 1 = open

You using the I3 flap and socket? I have not yet managed to convince the LIM its locked.

[asavage]

1B-13 is not on on the wiring info on ISTA, this only is referenced when you look at the Chademo version.

Made changes on wiki to match this info.

It seems my looking at the CHAdeMO pinouts led me to mess up the Wiki's charts. Thanks for that cleanup

Got a cheap chinese lock actuator wired back ward to put a 1K over the 10K for cable lock position feedback.

Doesn't the LIM require 11k for "locked". Paralleling 1k over 10k = 9k1 ?

[tom91]

Doesn't the LIM require 11k for "locked". Paralleling 1k over 10k = 9k1 ?

Wired like shown. The resistors are outside the actuator, but to make it properly work I will make a PCB to reverse the switch behaviour to allow the Chinese actuator to work with the I3 LIM.

[asavage]

I close the flap, switch on the ignition and lock the flap.
pin 12 open = closed flap
pin 12 GND = open flap.
You can see the flap status on 272h bit 16. 0 = closed, 1 = open

4B-12 COV FBK when not grounded it indicates being open over canbus based on the DBC file on github.

To confirm: are we agreed that 4B-12 floating == (0x272.16 == 1) == "Charge Port Cover is Open" ? The Wiki is currently in a indeterminate state on this point.

[later]
Confusingly, there's this from pg. 112 (indicated) from BMW ST1403a:

BMW ST1403a, pg. 112

Switches can be NO or NC, so the functional description doesn't/shouldn't imply the electrical circuit to provide that function, but still . . .

[muehlpower]

I close the flap, switch on the ignition and lock the flap. pin 12 open = closed flap/ pin 12 GND = open flap. You can see the flap status on 272h bit 16. 0 = closed, 1 = open

You using the I3 flap and socket? I have not yet managed to convince the LIM its locked.

No, I don't have a switch on the fuel filler flap. I simulate the fuel filler flap with the Arduino with a transistor to GND. My Chinese charge port switches a relay that switches the correct resistors to the LIM. The Arduino also receives and sends all CAN messages from the LIM, GEN 3 charger and the rest of the car. No Damien or Johannes board or software. By the way I have again Voltage sensing board if anyone is interested.

[tom91]

No, I don't have a switch on the fuel filler flap. I simulate the fuel filler flap with the Arduino with a transistor to GND. My Chinese charge port switches a relay that switches the correct resistors to the LIM. The Arduino also receives and sends all CAN messages from the LIM, GEN 3 charger and the rest of the car. No Damien or Johannes board or software. By the way I have again Voltage sensing board if anyone is interested.

I currently have not managed to get my bench setup to try and do the contactor wed test. I can post a can capture for review if you want to help out.

[tom91]

According to my documents, pin 3 is GND, 11,12,13 are NC, 15 is Charge Enable, corresponding to 3B4 bit 21. The return line for the locking signal is on pin 5, not on GND. The welding test only works if pin 5 on the 12-pin connchtor has 1.4V. This signals 0V DC at the charge port! And of course the DC contactor ports must be 16 ohms!

I have measured the pin 5 return from the HV measurement board it is at 1.439V and the canbus reports 0V on FC voltage. Contactors connected and measure at 15.8 ohm.

I took logs of my setup if anyone would mind having a look that would be great. https://github.com/Tom-evnut/BMWI3_LIM_ ... ch%20Test

The charge flap reports to be closed and I double checked the values of my messages with known working logs so all should be inline with what the LIM expects, however no weld check test is triggered.

One thing I am seeing is in Damiens logs the FC Contactor Test reports fail on the canbus even though the contactors cycle when requested during charging.

[muehlpower]

Your value of byte 2 on CAN 272h is 00. That means DC contactors are OK, so no weld test necessary. You can fake a voltage on the charge port (e.g. 2V on pin 5) and then set it back to 0V.
You should be able to observe on CAN 272h a change to 18h while the DC voltage is present , then 8h during the test and then 0 again

[tom91]

You should be able to observe on CAN 272h a change to 18h while the DC voltage is present , then 8h during the test and then 0 again

Does the test occur automatically? As coding I found in the beginning of the thread https://openinverter.org/forum/viewtopi ... 409#p28409
Has options to trigger a request to test.

[tom91]

Thanks guys. They have cycled

I applied 100V to the sense lines and removed them and then the contactors cycled after toggling the ignition in 0x12F byte 2 from 0x88 to 0x8a.

My Lim is a 2016-12 date

[tom91]

Here is some pictures of my current setup. Now I got the contactors to cycle I will start to build my HV junction box and try to clear the contactor test fault, using my HV power supply on the battery side of the HV contactors once I have forced it into a fault condition.

Is there a way to get the 2016-2017 LIMs to preform this test without having to force it into a fault condition with Voltage first?

[tom91]

Added, a start for the contactor test section.

[muehlpower]

byte 2 = 60h means unexpected DC voltage on the CP, not "test failed". What are you using to measure the voltage on the CP?

[tom91]

byte 2 = 60h means unexpected DC voltage on the CP, not "test failed". What are you using to measure the voltage on the CP?

I have a 400V power supply that I fed into a EVcreate board.https://www.evcreate.nl/shop/charging/v ... mw-i3-lim/
So it seems to work as other have described. Due to not having the full setup built I have no voltage doing through the contactors for now.
So next step is to build a test setup and get it so it says that the weld check has passed.

There has to be a cleaner way of forcing the LIM to do a contactor check, the forcing it into a fault state.

Do you have a value table for 0x272 Byte 2 that we can add into the .dbc?

[EV_Builder]

byte 2 = 60h means unexpected DC voltage on the CP, not "test failed". What are you using to measure the voltage on the CP?

CP as in charge port? (I know you meant that but Control Pilot = CP too).

Maybe it would have expected voltage and there was/came none?

Does someone know any 15ohm relais with Manny amps?My Taycan setup should be capable of some power and how many C's are those relais? Find it difficult to let the numbers match. Many components don't line up. Between nominal and peak.

[tom91]

I have been able to get the byte 2 of 0x272 to reliably clear, however the dbc says the contactor test result is also in this byte. Is this true or is this just a red herring as Damiens log of charging on github shows the contactor test result as false.

Would having the LIM clear byte 2 of 0x272 be enough to allow CCS charging to happen?

[muehlpower]

I hope your German isn't rusty


18/6 ST_DCSW_DC_CHGNG Status_Trennschalter_Gleichstrom_Laden

Bit 0 = 0 DC-Ladeschütze geöffnet (mindestens 1 Schütz geöffnet)
Bit 0 =1 DC-Ladeschütze geschlossen (beide Schütze geschlossen)
Bit1 = 0 Schützansteuerung ok
Bit1 = 1 Schützansteuerung Fehler
Bit 2 bis 5
0000 DC-Ladeschütze ok
0001 Noch keine Schützkleberdiagnose durchgeführt
0010 Schützkleberdiagnose läuft
0011 Letzte angeforderte Schützkleberdiagnose konnte nicht durchgeführt werden
0100 Einfacher Schützkleber erkannt
0101 Doppelter Schützkleber erkannt
0110 Unerwartete Gleichspannung an Ladedose
0111 Doppelter Schützkleber bei letzter Diagnose erkannt, Ladedose aktuell spannungsfrei
111101 Signal nicht verfügbar
111110 Fehler
111111 Signal ungültig

16/2 PO_CHGF Position_Ladeklappe

00 Ladeklappe geschlossen
01 Ladeklappe geöffnet
10 Fehler
11 Signal ungültig

[tom91]

I hope your German isn't rusty

Thank you I will get on translating this into the DBC.

Is there any status byte that will indicate that during CCS charging the contactors will close?

Seeing that Damien had this issue in the past and other experienced the same thing. It would be good to incorporate a way of detecting the LIM not being ready to control the contactors during charging so they can be forced to cycle.

[muehlpower]

my program monitors byte 2. If bits 2 to 5 are not equal to zero, a weld test is initiated. So I close the flap, turn on the ignition until bit 2 to 5 is zero again, than I open the flap and turn off the ignition.

BTW, your 1.43V for 0V is very tight. I make my boards from 1.38V to 1.4V. The LIM still reports 0V down to 1.23V. This makes the zero position more stable.

[asavage]

The .dbc has an anomaly for 0x272 (626). The signal FC_Contactor_Test is defined as big-endian (Motorola, etc.) when almost all the other signals in the .dbc are defined as little-endian (Intel, etc.):

Code: Select all

BO_ 626 LIMMsg272: 8 LIM
 SG_ FC_Contactor_State : 18|6@1+ (1,0) [0|24] "" Vector__XXX
 SG_ ChargeFlap_Status : 16|2@1+ (1,0) [0|4] "" Vector__XXX
 SG_ FC_Contactor_Test : 19|1@0+ (1,0) [0|1] "" Vector__XXX

Unless there's a good reason, in that last line, "@0+" should probably be "@1+".
Damien added that line in Jun2021, and it doesn't look to have been changed since.

[later]
Also, my .dbc lint checker brought up another issue here: the offsets overlap for FC_Contactor_State (18:6) and FC_Contactor_test (19:1). I'm surprised this didn't create issues before.

I've just installed the free .dbc editor from Vector, CANdb++ Editor, and it picks this stuff up and flags it. CANdb++ is unfortunately Win-only, but fortunately seems to run OK in a Win VM here.

It shows the same endianness issue with the PP_Status signal.

---

Before you start writing enums and vals, you'll want to sort out that overlap at least. I don't have the hardware or test setup you do, so I don't want to be suggesting specific changes, but switching byte order/endianness, and the field overlaps are things that should be reviewed, I think.

[tom91]

The .dbc has an anomaly for 0x272 (626).

That is why I asked for this info I am redoing that byte as its not correct.

[EV_Builder]

I can post the user class for the DBC for the public when its finished. its auto created c++. You get a class per message with properties to read/write and methods to get or set the canbus message.
Saves allot of time!

All naming and info comes from the DBC file.