Hyundai Kona CCS controller Topic is solved

[uhi22]

Regarding to the CAN signals: There must be a lot of handshaking with the other components, because the CCM itself has no hardware link to them. I expect at least the following:
- The OBC says "detected 5% PWM", this should trigger in the CCM the initiation of the PLC communication.
- The CCM says "charger wants to know the charging parameters".
- The BMS says the parameters (voltage, SOC, capacity, ...)
- The CCM says "lock the connector"
- The car says "connector is locked"
- The CCM tells the OBC "change from stateB to stateC". In the OBC, this turns on an additional resistor on the CP line.
- The OBC tells the CCM "stateC done".
- Alignment between car and CCM regarding contactor closing and success.
- And vice versa, stateB, contactors opening, chargeport unlocking.

[projectgus]

Thanks @uhi22, that all makes sense. I was thinking that if AC charging works on the Ioniq with the CCM removed (as you documented), then the OBC must be doing all the J1772 logic for pulling down the 12V pilot, detecting the 12kHz PWM, etc. It would be weird to have that handled in two places on the car.

Is it possible the CP state change and connector locking logic is all handled by the OBC? From what I can tell, negotiating the start of a CCS session is the same as negotiating a J1772 AC charge session. In which case maybe the OBC handles this handshaking - locking the connector, etc - then at the point that it would start AC charging it detects the 5% CP duty cycle for "digital communication requested", and will send a single state update to the CCM to indicate "CCS ready" (maybe the trigger bit?) Then from there the CCM can start negotiating over PLC. Then the next state change would be to ask the BMS to close the QC contactors. I'm pretty familiar with J1772 but I don't know much about CCS, so I don't know if this is a possible sequence or not.

In any case, we'll try to hook up the GreenPlug AV modem tomorrow and get some packets flowing!

[uhi22]

Based on your suggestions and further investigations, added some more signals in the data base: https://github.com/uhi22/IoniqMotorCAN/ ... 9552d22e1b
I agree, that the "CCM_CCS_error" is not really an error, it also comes when successfully finished. So I renamed it to CCM_CCS_ended.

Edit: Further update regarding CCM_CCS_TCP_connected: https://github.com/uhi22/IoniqMotorCAN/ ... 9c8cf57d1e

[uhi22]

Is it possible the CP state change and connector locking logic is all handled by the OBC? From what I can tell, negotiating the start of a CCS session is the same as negotiating a J1772 AC charge session. In which case maybe the OBC handles this handshaking - locking the connector, etc - then at the point that it would start AC charging it detects the 5% CP duty cycle for "digital communication requested", and will send a single state update to the CCM to indicate "CCS ready" (maybe the trigger bit?) Then from there the CCM can start negotiating over PLC. Then the next state change would be to ask the BMS to close the QC contactors. I'm pretty familiar with J1772 but I don't know much about CCS, so I don't know if this is a possible sequence or not.

The connector lock in DC case is quite late. Before, the communication is already established and runs until the contractAuthentication (when the user needs to autorize). This means, detecting the plug and locking the connector in one shot should not happen in DC case.
The full sequence I described here: https://github.com/uhi22/pyPLC#example-flow (Of course this may be also wrong or incomplete, it's just what we found out until now.)

[uhi22]

Some progress with the Ioniqs CCM donated by @larsrengersen (thanks again): Reading the controllers memory worked. Also tracing the SPI between the controller and the QCA7005 was successful. This basically opens three different ways to re-use the CCM:
1. Keep it in original state, and just feed the appropriate CAN message to it. Still some investigations necessary to understand the handshake.
2. Hold the original controller in reset, and connect an other controller (ESP32, stm32, RaspberryPi, ...) to the SPI. The driver for the QCA is already included in Linux, so it is easy to just configure a Raspberry to drive the QCA via SPI, this creates a virtual eth1, and use pyPLC configured to this eth1.
3. Develop a new software for the original controller. Would be a quite long way, but would keep the original hardware and would offer full flexibility. If there would be an open-source development environment and some basic examples for this controller (for CAN and SPI), this way looks possible.

Stored the current results here: https://github.com/uhi22/Ioniq28Investigations

[brainstorm]

Hi uhi22, I'm projectgus' friend, helping him out with his FrakenKona

I also got a CCM to muck around a couple of days ago from another EV club friend and got to the point of having a Glasgow board talking with bitbang'd JTAG against OpenOCD. I've written up a few (not all) details from my setup here:

https://gist.github.com/brainstorm/ab2f ... d1a32a20ad

Unfortunately OpenOCD has some troubled and incomplete e200 support:

https://sourceforge.net/p/openocd/mailm ... nlr.menet/

May I ask how you managed to dump the contents of the main FreeScale SPC5606 IC? Like Mike Electric Stuff, I dumped the SPI flash 8 pin IC only to find the QCA drivers there, but not much application payload.

Cheers!

[uhi22]

Luckily we used the same controller family 10 years ago in a professional project, and the "blue box" debugger from ISystems was still flying around. The connector matches directly, so it was just plug &play
Would be interesting to know whether there is a working open-source solution for at least flashing, in best case also for debugging ...

[uhi22]

The toolchain for decoding the SPI traffic between the SPC5605 and the QCA7005 is working now.
- SPI is traced by Saleae logic analyzer, and exported as text file.
- The text file is converted to a pcap, using https://github.com/uhi22/Ioniq28Investi ... 1886e4a915
- The pcap can be converted to see the content of the V2G/EXI messages, using https://github.com/uhi22/pyPLC/blob/mas ... nverter.py
- Finally the result can be shown as osci plot, using https://github.com/uhi22/pyPLC/blob/master/scope.py

[uhi22]

Installed the CCM from Lars in my Ioniq and drove to a public charger to see whether this works. Results:
- Charging works. (Ok, not a really surprise. Both CCMs have the same part number.)
- SPI trace of a complete charging session recorded and decoded, results here: https://github.com/uhi22/Ioniq28Investi ... i-analysis

[uhi22]

Managed to read out the SPI flash and made some quick analysis: https://github.com/uhi22/Ioniq28Investi ... i-flash-u4

[uhi22]

To summarize the current status:
- From the CAN traces, created a (still weak) understanding how the CCM is talking with the rest of the car during a charging session. https://github.com/uhi22/Ioniq28Investi ... ng-session This needs to be refined to be useful. My conclusion for the moment is: The CCM is not really suited to play as a charge controller for not-Hyundai projects. Because it does no CP handling, no connector lock, no charge port temperature measurement. It is just a CAN to PLC bridge.
- The CCM helped a lot to understand the design of the QCA7005 together with its power supply, flash, microcontroller communication.
- Based on the gained knowledge, there is a way open to make an open-source implementation using ESP32 and QCA7005. The CCM works well for such a development (while it's original host controller is just hold in reset, so it does not disturb). https://github.com/uhi22/ccs32berta

[johu]

Awesome work. The difference between ccs32 and ccs32berta is one talks via SPI the other via Ethernet?

btw who are Dieter and Berta?

[uhi22]

The difference between ccs32 and ccs32berta is one talks via SPI the other via Ethernet?

Exactly. Fortunately only the transport medium is different between the QCA7005 (SPI) and AR7420 (Ethernet). The data itself is the same. It would make sense to have just one software with configurable interface setting, but at the moment they are separated playgrounds for "quick and dirty" experimentation.

I like simple, easy to remember names for things. In rare cases they relate to real persons (like Dieter, a friend of mine who rests in peace), often it's just alphabetical like the Berta from https://de.wikipedia.org/wiki/Buchstabiertafel