BYD/Dropbeats CCS controller module

[projectgus]

I had the chance to examine the CCS DC fast charging controller module from a BYD Atto 3 today, and thought I'd share some findings. This module is similar to the Hyundai one, as in it talks CAN messages on one side and negotiates the CCS2 PLC data link on the other side.

This module only has six pins connected in the Atto 3: 12V power, two grounds, CAN H/L and the charge port CP connection. It's on a dedicated "Charging sub-network" CAN bus with only two CAN nodes: this CCS module, and a port on the Integrated Intelligent Controller (basically VCU+OBC super-unit, inside the motor stack).

External label is mostly in Chinese (“车载CCS通讯转换器” is "Vehicle mounted CCS communication converter device"). There's also a serial number and a model number EKEA-2126080.

Inside, the PCB is very well labelled with a lot of test points:

(The photos look better zoomed in, but unfortunately still slightly blurry.)

The canned module on top is a Dropbeats DB2015V-A-S-Y QCA7005 PLC interface module.

Poking around the Dropbeats (Chinese name 奇鲸科技) website reveals the BYD module is a version of their DB EVCC 500 module. There is a 10 page "External" datasheet on that page, including a pinout that matches the BYD wiring diagram (with mirrored pin numbers). However it looks like the BYD version has the extra features of the OEM product (like the second UDS CAN port) unpopulated on the PCB.

The main microcontroller is an NXP FS32K148HRVLQ in LQFP144 package. Seems like a non-advertised variant of their S32K1 line. Cortex-M4F based microcontrollers with lots of automotive-focused peripherals.

I tried connecting to these pin headers on the board (as labelled on the bottom test points):

Both UARTs are 115200bps with 3.3V levels. First one:

Code: Select all

EVCC Bootloader, designed by Drop-beats. Version number: 1.0.1.
udsPef = 0x00.
UDS started.
UART1 console initialized!

eMobility_EVCC by Drop-beats. BSP Version number: 2.0.4.
The last build time: Mar 12 2024, 10:18:20

EEESize = 0x00001000.

Current board ID = 12

[sbcMode, prevMode] = [2, 0].
SBC Initialization succeeded!
SBC Monitor task created.
Elocker not enabled!
CORE_CLK = 80000000 Hz !

eMobility_EVCC by Drop-beats. APP Version number: 3.0.11.  NvParam Ver: 2
Application build time: Mar 12 2024, 10:19:35


A password is required to enter DBSH !

Waiting for PLC network to be ready ...
PLC network is ready !

PLC test passed!
dbsh>
dbsh>help
A password is required to enter DBSH !
dbsh>
dbsh>list
A password is required to enter DBSH !
dbsh> 

Second one:

Code: Select all

DBev>
DBev>
DBev>
DBev>help
Invalid cmd
DBev>h
Invalid cmd
DBev>u
Invalid cmd
DBev>list
Invalid cmd
DBev>
DBev>␀DBev>
DBev>help
Invalid cmd
DBev>up
Invalid cmd
DBev>info
Invalid cmd
DBev>a
Invalid cmd
DBev>b
Invalid cmd

As you can see I didn't have much luck interacting with them (first one requires a password, second one I couldn't guess any valid commands.)

The 10 pin header appears to be a standard 2.0mm pitch ARM Cortex-M debug header. This allowed SWD debugging immediately(!), like most automotive OEM stuff debugging seems to be left enabled.

Using pyocd I was able to dump the flash without any trouble, seems like this part has 1.5MB flash. Strings in the binary suggest it's based on FreeRTOS, and is a special firmware build for BYD. (Amusingly, even though I couldn't find this chip variant on the NXP website it's listed in the CMSIS support pack so pyocd pack install S32K148HRxxxLQx worked and then:

Code: Select all

$ pyocd cmd --target S32K148HRxxxLQx
Connected to S32K148HRxxxLQx [Running]: 00000080502032204a305030313030323131303197969903
pyocd> savemem 0x0 0x4000000 flash_dump.bin
Transfer failed: Memory transfer fault @ 0x00180000-0x00180fff
pyocd> savemem 0x0 0x00180000 flash_dump.bin
Saved 1572864 bytes to flash_dump.bin
pyocd> savemem 0x10000000 0x00180000 flexnvm_dump.bin
Transfer failed: Memory transfer fault @ 0x10070000-0x10070fff
pyocd> savemem 0x10000000 0x70000 flexnvm_dump.bin
Saved 458752 bytes to flexnvm_dump.bin
pyocd> savemem 0x1400_0800 128 cse_pram.bin
Saved 128 bytes to cse_pram.bin
pyocd> savemem 0x1400_1000 128 cse_pram2.bin
Transfer failed: Memory transfer fault @ 0x14001000-0x1400107f

I have to give this module back to my friend, and I have my own reversing project to worry about, so I'm done with this BYD module for now. However, I thought I'd mention it in case it's of interest for more DIY CCS hacking.

(The one thing we don't have yet is a CAN log, I think the only way to get one would be to probe the "Charging sub-network" while DC fast charging...)

[projectgus]

(The one thing we don't have yet is a CAN log, I think the only way to get one would be to probe the "Charging sub-network" while DC fast charging...)

I'd forgotten this CAN sub-network is also routed to non-standard pins on the OBD2 port, so this could be done from inside the cabin and without disrupting any wiring...

[Marat]

pin ?

[projectgus]

pin ?

According to the RHD wiring diagrams here, Charging sub-network CAN-H is OBD pin 9 (Pink) and CAN-L is OBD pin 10 (Violet). The same pink/violet colour scheme is used for multiple different CAN networks.

None of that matches the diagram you posted, though, so I'm not sure what to make of that.

[Jack Bauer]

Very good info thanks

[Turk]

If anyone with a BYD is looking at this post as a solution to the Tesla Supercharger V3/V4 incompatibility issue. The issue is with the Resistor hanging off the PP pin to 5v. Communications on the CP line work correctly. Look for my post in the charging section for more details.