QCA7000 Foccci+Clara User thread

[dougyip]

Still not working, but found some interesting troubleshooting information.

1) Verified that the charger is not in an error state by charging an Ioniq 5 before our test.

2) First test with the 330 ohm to 5V and 2.7K pulldown on the PP line. Response was identical to last trip with no communications established.

3) Second test with the 330 ohm pull-up and 2.7k pulldown removed and the board returned to it's original configuration with 1k pullup to 3.3V. Communications established once again (SOC displayed on the station and I receive EVSE Max Voltage and EVSE Max Current). The system fails at the "Cable Check Request" - same as our original test.

4) 0% duty cycle reported on PP on "Spot Values" and in log.

[uhi22]

Ok, at least the results are stable, that's a good basis for finding the issue.
There are two indications, that something with the wiring is wrong:
- The CP PWM is reported with 0%. This shows that either the CP is not wired to the charger, or the charger does not provide the PWM at all.
- The cableCheck fails. One reason for this is, that the charger does not see the state C on the CP (but there are other reasons, too).
The surprising fact is, that even if the CP is not connected, there could be still the high-level-communication ongoing. I observed this also in my experiments. Just a very weak coupling is sufficient, e.g. two wires sit with some millimeters distance, so the high frequency PLC signals (2MHz to 30MHz) are able jump to via the capacitive coupling between the wires.

Do you have access to an oscilloscope? I'd propose to measure the CP signal on Foccci board. As long as the charger is not plugged-in, the CP shall have 0V. When plugging in, the CP shall jump to 9V (because the charger supplies 12V via 1k on the CP, and the Foccci has a diode and pull down). This is the state B. As soon as the charger detects the state B, it shall start the 1kHz, 5% PWM. This may be fast (e.g. few milliseconds) or longer (e.g. half a second or so). The PWM shall have the levels +9V and -12V. And the duty of this PWM shall be visible in the Focccis web interface.

[dougyip]

Success! Completed multiple test sessions today at 20, 40, and 80kW. Thanks to all for the help! What was the problem? CP & PP lines mixed up - oops! Interesting that there was still some communications over the CP line despite no direct connection.

1) We would have tried 120kw as well, but CAN variable "Charge Current" is only an 8 bit variable. It appears we can only specify up to 256 amps. I tried changing the CAN map to 16 bits without success.

2) It looks like actual EVSE Current = Commanded Charge Current at any SOC lower than 95% (see point 3 below). This means that most current ramping we see on OEM vehicles starting at 80% SOC is being implemented on the vehicle side.

3) It appears that SOC is not strictly for display (at least on the PhiPhong charger). It does enforce some safety monitoring. The charger faulted out and would not restart when we hit 95% SOC (number was incorrect, we were probably closer to 75%) with 80kW charge power. When the transmitted SOC number was changed to 75%, were able to re-start and continue at 80 kW.

For those of you interested, I will post a project update about the vehicle in the appropriate section once we have our 2024 Upgrades sorted out. As well as the CCS charging upgrades, we have stretched the car 10", and added a 2nd M3 drive unit to make the car AWD....

[uhi22]

Regarding the "8 bit" for the ChargeCurrent: Cannot confirm this issue at the moment. Using SavvyCAN to transmit the value 499A (hex 01F3), and this shows up in the web interface:

image.png (6.32 KiB) Viewed 9513 times

Using this CAN mapping:

image.png (3.58 KiB) Viewed 9513 times

The path in the software from the parameter itself to the CCS structure uses at least int16, so should not limit. The limitation I found is the 500A in the parameter definition. Could you check which value shows up in the web interface, if you have on CAN a value between 256 and 500A?

[Edit] Also pyPLC shows the correct current up to 500A:

[dougyip]

I also get it working in the test bench now - not sure why I couldn't get it working in the field. Good to know it isn't a fundamental problem with the data structure. Isn't " Charge Current" mapped to 0x102 (Decimal 258) though? I remapped to length 16 starting at position 24 and can now receive numbers between 256 and 500.

[uhi22]

Great. I just used a random ID, for me it does not matter.

[evMacGyver]

I got hacked AC interface working with Zombie, few more CAN mapping and some code changes. Clara mods was acOBC main like comment says locking and unlocking. Also calling hardwareInterface_stopChargeRequested() while charging to get button work.

I could not yet get pyPLC EVSE to communicate with Focci using 1k5 resistor on PP and 5% CP. Now I have verified my pyPLC EVSE board to communicate with pyPLC PEV board correctly.

I have CAN mapping for chademo, zombie chademo module DCFCRequest function have DCFCREQUEST which should be digital input.
Also mapped Focci to send CableCurrentLimit, so perhaps replacing digital input with "Param::GetInt(Param::CableLim) == 13" could get zombie to begin charging process. Maybe ControlPilotDuty == 5 would be better, but zombie does not have parameter for it.

What are least minimum things for Clara to communicate with pyPLC EVSE, after 1.5k PP and 5% CP? Are those chademo mapping; BatteryVoltage, TargetVoltage, ChargeCurrent, enable, soc? Or does enable without another parameters get Focci communicate with pyPLC EVSE?

[uhi22]

Foccci/Clara are quite relaxed regarding the preconditions for starting the high level communication. Neigher the PP nor the 5% PWM nor the StateB (9V) on CP is necessary. Only power, and starting with version 4.5 something to wakeup (e.g. wakeup line). This should be sufficient to be get a demo charging session with pyPLC in EvseMode.
I'd propose to make a log of the serial debug output, to see what happens.

[evMacGyver]

Here is the serial log, thank you for helping! PP and CP was already connected to charge port and after that connected Focci. At one point I removed PP resistor for a while and did same for CP bit later. Pretty much nothing happening on pyPlc in evse mode. I did not send any CAN messages during this.

Log shows PP almost 1k2, it is really 1.5k. Just slightly above 1k5 * 0.8 limit and should be ok for now. Don't really know why it shows lower value, need to investigate this.

Is that ETH rx valid or is there some problem with CP circuit?

[uhi22]

[70] [PEVSLAC] received GET_SW.CNF
For MAC 00:b0:52:00:00:01 software version BootLoader
means the QCA is stuck in bootloader, it was not able to load the firmware from the SPI flash. Where did you get the Foccci from?

(Edit) This also covered in the Foccci troubleshooting guide
https://github.com/uhi22/foccci?tab=rea ... tis-normal

[evMacGyver]

Oh right, sorry I bothered you with this! I totally forgot to do that on this board, silly me.

[uhi22]

No problem, everything perfect if it runs afterwards

[evMacGyver]

I got Focci/Clara working with pyPLC in EvseMode. ZombieVerter send zeros as batvtg (0x100) and precharge did not complete (accu 0V), replacing batvtg with correct udc value fixed it. I think its needed for real charging session too:

Code: Select all

void FCChademo::Task100Ms()//sends chademo messages every 100ms
{
   uint32_t data[2];
   bool curSensFault = curTimeout > 10;
   bool vtgSensFault = vtgTimeout > 50;

   //Capacity fixed to 200 - so SoC resolution is 0.5
   data[0] = Param::GetInt(Param::udc); // <== this line changed
   data[1] = (targetBatteryVoltage + 40) | 200 << 16;
   ..

Calibrated analog input BMW LIM 4..20mA measurement, HV zero input needs to be scaled down. Now with UdcDivider 2.78125 is close enough:

Code: Select all

      case IVSRC_ANAIN:
         #define hv_offset 562
         uint16_t hv_reading;
         hv_reading = AnaIn::udc.Get();
         if (hv_reading - hv_offset <= 0)
            hv_reading = 0;
         else
            hv_reading -= hv_offset;
         Param::SetFloat(Param::InletVoltage, hv_reading / Param::GetFloat(Param::UdcDivider));

Next to charging station Many thanks for great work with Focci&Clara!

[uhi22]

ZombieVerter send zeros as batvtg (0x100) and precharge did not complete (accu 0V), replacing batvtg with correct udc value fixed it. I think its needed for real charging session too

Good point. Yes, we need the actual battery voltage during the precharge phase. Did @johu publish his Touran-Chademo-Battery-Voltage-Extension somewhere? Should be the same as you now did.
[Edit] But wait, you are using one byte to transport the voltage. If the resolution is 1V, then only 0V to 255V are supported. Is this intended? Or is the scaling different?
[Edit2] Forget what I said, the data has 32 bits, everything fine.

Calibrated analog input BMW LIM 4..20mA measurement, HV zero input needs to be scaled down. Now with UdcDivider 2.78125 is close enough

Next good point. Seems you are the first who tests the analog voltage measurement. Until the analog value is just linearily scaled with UdcDivider, but this is clearly wrong, because the sense board has 4mA for zero input. Created an issue https://github.com/uhi22/ccs32clara/issues/23 and will take your proposal as template for a fix. Many thanks.

[johu]

Did @johu publish his Touran-Chademo-Battery-Voltage-Extension somewhere?

Yes https://github.com/jsphuebner/stm32-car ... o.cpp#L120

I did it in a way that stays compatible with actual CHAdeMO chargers. So only puts voltage in there if version "10" is indicated. Largest actual CHAdeMO version is 3

[evMacGyver]

My home EVSE is Tesla Wallbox gen 2. Does anyone know is there something tricky with these, does it try to communicate using 5% CP?

This is only AC EVSE I have not got working, now grabbed serial log and it seems to start with 5% and then to 0%. Customized Zom begins AC charge if CableCurrentLimit != 13A and there is valid EvseAcCurrentLimit != 0. Ideas?

[celeron55]

My home EVSE is Tesla Wallbox gen 2. Does anyone know is there something tricky with these, does it try to communicate using 5% CP?

I'm guessing it tries to communicate using 5% CP with Tesla's proprietary protocol first, and if the car accepts that, it stays in it. If the car doesn't accept it, then it will switch to standard CP.

Is the problem that foccci/clara enables state C if it sees 5% CP even if the charger isn't talking a known protocol?

[asavage]

I'm guessing it tries to communicate using 5% CP with Tesla's proprietary protocol first, and if the car accepts that, it stays in it. If the car doesn't accept it, then it will switch to standard CP.

No data, but that's similar to how the Tesla Wallbox operation (GEN1) was described to me years ago.

[evMacGyver]

Is the problem that foccci/clara enables state C if it sees 5% CP even if the charger isn't talking a known protocol?

Not sure should stateC show in the serial logs, I believe (but not verified) it was not activated yet by VCU chademo FC code. Strange is why wallbox stops totally sending CP. Anyways clara isBasicAcCharging prevents AC charge without valid 8..96% CP.

In my previous setup before foccci I most likely just activated stateC when PP was detected.

[evMacGyver]

Now that I set up serial port, here is my next mystery. I have problem with CCS with few station types.

ABC stations uses Kempower, works sometimes, mostly not. Logs from exactly same station that was the first place to test foccci (which was success in first try).
K-lataus/Citymarket not sure manufacturer never worked, Tesla driver at the same station said that was Siemens. No serial logs yet from this.

Today tried three times; first I authenticate and plugged afterwards, next plugged first then authenticate and third the same but different plug.
All seems to end to "User requested stop on charger side" which is not true..

[evMacGyver]

Tested few stations today with no success. Found sometimes fail reason being locking motor that explains only few failures. Back at home tried pyPLC EVSE which works with no problem. Am I doing something wrong?

Today was similar as yesterday, except some different stations did not give Checkpoint790 termination.

Current demand fails timeout similar on many stations:

[19830] Turning on charge port contactor 2
[19860] [TCP] sending ACK
[19860] Data received: 01fe800100000029809a020dcc8d8c8cce0d4e50e00040800001028408b01818000000060a1e806030307d02038500f800
[19860] TCP will transmit: 01fe800100000023809a020dcc8d8c8cce0d4e50d1400a00c0c0bc6001810580480c08360100c143340800
[19920] [TCP] sending ACK
[19920] Data received: 01fe800100000029809a020dcc8d8c8cce0d4e50e08043000001828490101818000000060a1e806030307d02038500f800
[19920] TCP will transmit: 01fe800100000023809a020dcc8d8c8cce0d4e50d1400a00c0c0c06001810580480c08360100c143340800
[19980] [TCP] sending ACK
[19980] Data received: 01fe800100000029809a020dcc8d8c8cce0d4e50e080430000010285f8a81818000000060a1e806030307d02038500f800
[19980] TCP will transmit: 01fe800100000023809a020dcc8d8c8cce0d4e50d1400a00c0c0c06001810580480c08360100c143340800
[20570] In state CurrentDemand. TcpRetries 0
[20790] [CONNMGR] 165 0 0 138 0 137 303 --> 100
[21570] In state CurrentDemand. TcpRetries 0
[21780] [CONNMGR] 165 0 0 105 0 104 270 --> 100
[22570] In state CurrentDemand. TcpRetries 0
[22770] [CONNMGR] 165 0 0 72 0 71 237 --> 100
[23570] In state CurrentDemand. TcpRetries 0
[23760] [CONNMGR] 165 0 0 39 0 38 204 --> 100
[24570] In state CurrentDemand. TcpRetries 0
[24750] [CONNMGR] 165 0 0 6 0 5 171 --> 100
[24960] In state Timeout. TcpRetries 0
[24990] Safe-shutdown-sequence: setting state B
[24990] In state WaitForChargerShutdown. TcpRetries 0

Only change I've done recently is 10k series resistor for 3v3 regulator wakeup pin, should not affect.

This Efacec station gives DTC 10014, which is "over current in output". Only possible I could think is that contactors are closed too soon? Now InletVtgSrc = ChargerOutput, not analog input.

[evMacGyver]

Lightbulb! Looked into zombie oic logs when charge tests failed, it seems CCS_Ireq rises before actual power delivery and maybe some chargers does not like it. Earlier I did have set flash value of CCS_ILim lower and manually pump it up after charge process started.

So maybe need to watch for CCS_State (clara opmode) being 5 of 6 before starting request current. Did not check what opmode is what, in logs it seems to rise from 0 to 6 and after fail back to 0.

[uhi22]

Seems we have to investigate some interesting cases. Will have a look to the logs when I'm back home next days. To sort out defect chargers, it would be helpful to have a successful charge with an other before testing foccci.
The time of the CCS_Ireq should not matter. Because it will be used only in the currentDemandRequest, and the charger shall just use this or have it's own limitation or ramping.

[asavage]

I'm guessing it tries to communicate using 5% CP with Tesla's proprietary protocol first, and if the car accepts that, it stays in it. If the car doesn't accept it, then it will switch to standard CP.

I found where I'd read something on this, in a discussion of DCFC and how Tesla designs their OBC to accept tolerate HVDC on their AC input lines. Operation is described in Tesla's 2012 Model S Service Manual, Theory of Operation section. From our Wiki:




Reading that, it's not clear that when the document uses the term, "CAN" that it means what we think of as CAN (ie, as you said: proprietary).

I'm guessing that when the Wallbox is connected to an early Model S (with which all Tesla Wallboxes must be compatible), it sends "CAN", and a real Tesla (at least old ones) respond, but a non-Tesla car fails to repsond, and after a few seconds of no response the Wallbox switches to PWM 1kHz.

[uhi22]

Today tried three times; first I authenticate and plugged afterwards, next plugged first then authenticate and third the same but different plug.
All seems to end to "User requested stop on charger side" which is not true..

I checked the logs of the Kempower sessions.
1. In the chargeParameterRequest, Foccci announces EVMaximumVoltageLimit=330V.
2. PreCharge is successfully reaching 303V.
3. In the CurrentDemandRequest, Foccci is requesting EVTargetVoltage=333V. This is more than the announced maximum.
4. After a few loops, the charger is not happy anymore, and says in the CurrentDemandResponse "EVSEStatusCode_text": "EVSE_Malfunction".
5. Foccci ignores this, and keeps requesting current, and now the charger says "ResponseCode": "FAILED_SequenceError" and "EVSEStatusCode_text": "EVSE_Shutdown". Foccci interprets the EVSE_Shutdown as "User requested stop on charger side."

This shows two issues:
- The configuration is wrong. The EVMaximumVoltageLimit should be configured to a absolute maximum, which is never reached in normal conditions. It acts as an emergency threshold, to shutdown if something goes wrong.
- The Foccci does not react on the EVSE_Malfunction. We should add the feature to the software, that it clearly shows this abort reason. Issue created: https://github.com/uhi22/ccs32clara/issues/29