Safety Controller

Overview

The Charge SOM platform is equipped with an additional MCU (aka Safety Controller) which is responsible for managing all low-level aspects which are critical for electrical safety. The firmware for this MCU is developed by chargebyte and is not open-source. The Charge SOM boards ship with the safety controller firmware preinstalled.

The host controller firmware, e.g. the Linux system, communicates with the safety controller using an UART. On Linux side, this is UART interface /dev/ttyLP2. The communication with the safety controller firmware over this UART requires a proprietary protocol, see the following chapter. The required UART settings are listed in the following table.

Setting

Value

Linux Interface

/dev/ttyLP2

Baudrate

115200

Databits

8

Parity

none

Stopbits

1

System Architecture

_images/system_architecture.svg

Fig. 10: Simplified System Architecture for the Safety Controller on the Charge SOM platform

The safety controller manages the Control Pilot (CP) line, acting as a critical interface for monitoring and controlling the high-voltage (HV) system in accordance with EV safety standards. Its core function is to enforce safe operating states based on system diagnostics and environmental conditions.

Fault Detection & Safety Response

When an error is detected — such as a fault in the system, a triggered emergency input, or a thermal violation — the controller transitions to State F, a fail-safe state that prevents further system operation to protect both the hardware and the user.

HV Ready Enablement

The controller verifies that no system errors are present and that the CP line is in State C. Only under these safe conditions it does enable the HV Ready signal, which may be used to energize the HV interlock or permit charging/operation.

Emergency Inputs

The simplified system architecture shows only one emergency input. In the real system, there are 3 independent emergency input signals available: SAFETY_ESTOP1, SAFETY_ESTOP2 and SAFETY_ESTOP3. The inputs are active low. This means an emergency stop needs to pull the input to Gnd. The emergency inputs can be parameterized out.

Temperature Monitoring

The simplified system architecture shows only one temperature input. In the real system, there are 4 independent temperature measurement circuits for PT1000 sensors. The safety software monitors the temperature circuit for hardware errors and for overtemperaure. The temperature threshold can be parameterized.

HV Contactor Control

If State C is confirmed and all safety criteria are met, the controller is also capable of closing HV connectors to complete the high-voltage path. Therefore it enables the 2 connectors SAFETY_HVSW1_HS and SAFETY_HVSW2_HS under the condition that State C is detected, the system is HV-ready and the host processor commands to close the contactors.

Reset Behaviour and Controller States

The safety controller starts in an initialization state, to give the peripherals time to reach a defined state. It leaves the initialization state to a running state, after the reception of the first UART message from the host. Only periodic messages leave the init state. With the reception of inquiry messages, the safety controller stays in initialization. This gives the option to fetch version information in the init state. In running state, it monitors the peripherals and sends out UART messages. If any error occurs, the system goes into safe state. This state can only be left by a reset.

_images/safety_controller_states.svg

Safety Controller Parameterization

Overview

The safety controller can or must be parameterized to a certain extent. For example, it is required to know which temperature channels are actually in use and at which temperature thresholds the charging process needs to be stopped to avoid injuries to users and/or prevent damage to the EVSE itself. Futhermore, the safety controller can control high-voltage contactors and can then monitor feedback contacts to detect contactor welding. It also supports up to four emergency input channels, each can be disabled when not connected/required in the actual customer setup.

These safety controller parameters are stored as a binary parameter block, directly in the safety controller’s flash. When shipped from factory, there is a default parameter block installed which allows easy evaluation of the product, but is not intended for production usage in the field. Customers are encouraged to adjust the parameters to their requirements/needs during deployment of the board into an actual charger.

To adjust the parameters, some small command line tools are included in the shipped Linux firmware which allow to create/modify the parameters on the board itself. However, it is also possible to use these tools on a Linux host system (e.g. in a virtual machine) and then to transfer the created parameter block to each board and install it.

The mentioned tools are part of the ra-utils repository on Github.

To make the handling of parameters human-friendly, all parameters can be put together using a YAML text file.

version: 1
pt1000s:
  - abort-temperature: 75.0 °C
    resistance-offset: 0.85 Ω
  - abort-temperature: 85.0 °C
    resistance-offset: 1.042 Ω
  - 80.0 °C
  - disabled

contactors:
  - type: without-feedback
    close-time: 100 ms
    open-time: 100 ms
  - without-feedback
  - disabled

estops:
  - active-low
  - disabled
  - disabled

Important

The YAML file is required to be encoded in UTF-8. While most parameters are ASCII only, temperature thresholds require trailing °C suffix which has a special UTF-8 encoding sequence. This might be displayed incorrectly in the editor when editing on the device itself and/or finally stored wrong in the YAML file. The same applies to the resistance offsets in Ohm. When unsure, adapt/create the YAML file on your Linux host system with your preferred editor and transfer it to the board via Ethernet network (e.g. SCP/SFTP).

Such a YAML file must be converted to a binary parameter block file afterwards. And this binary parameter block file must finally be flashed to the safety controller’s flash memory, see below.

Important

The YAML file allows to specify a numeric parameter block version. This version is used internally by the safety controller firmware to detect the binary structure of the parameter block. It must thus match the safety firmware’s expectation, otherwise the safety controller will refuse to work and enters safe state directly.

Temperature Channel (PT1000) Configuration

The safety controller supports up to 4 PT1000 temperature channels. Thus the YAML file expects for each channel a temperature threshold in °C at which the safety controller stops and/or prevents charging. Also for each channel, an offset value in Ohm can be specified. This offset depends on the actual physical wiring and must be determined in the specific customer setup. If a PT1000 channel is not wired/used, it is required to disable this channel using the special word disabled instead of a temperature value. The example YAML file above shows that the PT1000 configuration is an array with up to 4 items. Each item can either be a single temperature threshold, the special token disabled or it is a key-value list. Valid keys are abort-temperature and resistance-offset. If no resistance-offset is given, then it is assumed to be zero.

The accepted value range for abort-temperature is -80.0 °C to 200.0 °C and it is stored with one decimal digit.

The range for resistance-offset is -32.0 Ω … 32.0 Ω, stored with three decimal digits internally.

Contactor and Contactor Feedback Configuration

The safety controller allows to control up to 3 high-voltage contactors and can monitor corresponding feedback contacts. The feedback contacts support Normally Closed and Normally Open semantic, but customer must follow chargebyte’s Charge SOM’s EVB reference design otherwise the logic might be inverted.

_images/charge_som_contactor_feedback_evb-circuit.drawio.svg

Fig. 11: Simplified Reference Circuit used on Charge SOM’s EVB for Contactor Feedback Signal

In the YAML parameterization, it is possible to specify whether the safety controller should actually switch the corresponding output pin and whether to monitor the feedback input pins. When using the feedback, it is also required to specify the opening and closing times of the used contactor. These times are expected in milliseconds and used by the safety firmware to check after the given time whether the feedback pin has the expected level. If the level differs from the expectation, then the safety firmware assumes a malfunction and thus enters safe state.

The example YAML file above shows all allowed variants how to parameterize a contactor. Possible values for the type are:

  • disabled

  • without-feedback

  • with-feedback-normally-open

  • with-feedback-normally-closed

Since the open/close timings make no sense in case of disabled or without-feedback, it is possible to use these tokens directly as array item (actually, it is also possible to use the with-feedback… ones, but then the timings are considered zero which will result in an error due to the physical latency in the contactor).

Both close-time and open-time accept integer values in the range 10 to 2550 ms. Internally, the safety controller operates with time slots of 10 ms, so the last digit of the given integer is just discarded. (In other words, the given integer is integer-divided by 10 before it is stored in the parameter block.)

Emergency Input Configuration

The safety controller can monitor up to 3 emergency inputs.

Possible configuration values are:

  • disabled

  • active-low

Installing a Parameter Block

Once the YAML file is created and fits your charger setup, it is required to convert it to a binary parameter block file. In the mentioned repository, there exists a tool ra-pb-create to generate such a binary file from the YAML file. The following session transcript shows how the install procedure works:

# create a YAML file on-the-fly
$ cat <<EOL > /tmp/my-parameters.yaml
version: 1
pt1000s:
  - abort-temperature: 85.0 °C
    resistance-offset: 0.85 Ω
  - abort-temperature: 75.0 °C
    resistance-offset: 1.1 Ω
  - disabled
  - disabled

contactors:
  - without-feedback
  - without-feedback
  - disabled

estops:
  - active-low
  - disabled
  - disabled
EOL

# convert YAML to binary
ra-pb-create -i /tmp/my-parameters.yaml -o /tmp/my-parameters.bin

# stop EVerest - to have exclusive access to safety controller
systemctl stop everest

# flash the parameter block
ra-update -a data flash /tmp/my-parameters.bin

# restart EVerest
systemctl start everest

Checking the Installed Parameter Block

To check which settings are currently used by the safety controller firmware, it is possible to read back the parameter block.

systemctrl stop everest
ra-update -a data dump | ra-pb-dump

This will print the current settings in YAML format on stdout.

Safety Controller Communication Protocol

Packet Format Description

Data packet format

Data packets contain payload and can be sent out from host to safety controller or vice versa. Data packets from safety controller to host can be transmitted periodically or by request via an inquiry packet. Only one inquiry packet can be requested before requesting the next one.

Symbol

Size

Code

Description

SOF

1 byte

0xA5

Start of Frame

ID

1 byte

Packet Identifier

Data

8 byte

Payload

CRC

1 byte

CRC Checksum

EOF

1 byte

0x03

End of Frame

Packet Identifier (ID)

The values of the packet identifier (PacketId) are mapped to the messages as summarized below.

PacketId

Description

Communication Dir.

Periodicity

Triggered by Inquiry

0x06

Charge Control 1

Host → Safety

periodically, every 100ms OR immediately if changes occur

No

0x07

Charge State 1

Safety → Host

periodically, every 100ms

No

0x08

PT1000 State

Safety → Host

periodically, every 100ms

No

0x0A

Firmware Version

Safety → Host

no, only upon request via inquiry packet

Yes

0x0B

GIT Hash

Safety → Host

no, only upon request via inquiry packet

Yes

0xFF

Inquiry Packet

Host → Safety

no, only to trigger inquiries

No

CRC Checksum Field

The checksum is defined over:

Width       = 8
Poly        = 0x1d
XorIn       = 0xff
ReflectIn   = False
XorOut      = 0xff
ReflectOut  = False
Algorithm   = table-driven
Name        = CRC8 SAE J1850

ChargeControl1

ID: 0x6 (6)

Length: 8 bytes

Description: This message shall be sent from the host processor to the safety controller to control the peripherals connected to the safety controller.

Senders: chargeSOM_HostController

Table 9: Signals in ChargeControl1

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

CC_TargetDutyCycle

1

10

Big Endian

No

0.1

0

%

Duty cycle between 0.0 and 100.0%. Values above 100.0% are set as 100%. Only valid if the signal CC_PWM_Active is 1

CC_PWM_Active

7

1

No

1

0

This flag indicates if the PWM should be activated. At a value of 0, the CP level is also 0V. At a value of 1, the CP level is dependant of the duty cycle

CC_Contactor1State

16

1

No

1

0

Request to close the contactor state. A value of 0 means open contactor, a value of 1 means closed contactor. The contactors are only closed if the system has no errors and is in state C.

CC_Contactor2State

17

1

No

1

0

Request to close the contactor state. A value of 0 means open contactor, a value of 1 means closed contactor. The contactors are only closed if the system has no errors and is in state C.

CC_Contactor3State

18

1

No

1

0

Request to close the contactor state. A value of 0 means open contactor, a value of 1 means closed contactor. The contactors are only closed if the system has no errors and is in state C.

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<-x|   |   |   |   |   |<------|
      +---+---+---+---+---+---+---+---+
        +-- CC_PWM_Active
      +---+---+---+---+---+---+---+---+
    1 |------------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- CC_TargetDutyCycle
      +---+---+---+---+---+---+---+---+
    2 |   |   |   |   |   |<-x|<-x|<-x|
B     +---+---+---+---+---+---+---+---+
y                           |   |   +-- CC_Contactor1State
t                           |   +-- CC_Contactor2State
e                           +-- CC_Contactor3State
      +---+---+---+---+---+---+---+---+
    3 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    4 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    5 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    6 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    7 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+

ChargeState1

ID: 0x7 (7)

Length: 8 bytes

Description: This message shall be sent from safety controller to host processor for indicating the state of the charging session as well as the state of connected peripherals.

Senders: chargeSOM_SafetyController

Table 10: Signals in ChargeState1

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

CS_CurrentDutyCycle

1

10

Big Endian

No

0.1

0

%

The current duty cycle between 0.0% and 100.0%. If the PWM is not aczive this signal is 0

CS_SafeStateActive

3

2

No

1

0

This signal reports, if the controller is in safeState or not.

CS_PWM_Active

7

1

No

1

0

Feedback if PWM is active. 0 means not active, 1 means active

CS_CurrentCpState

18

3

No

1

0

Current state of the control pilot. See value mappings below

CS_CpShortCircuit

19

1

No

1

0

Is set when the safety controller detects a short-circuit condition between CP and PE line.

CS_DiodeFault

20

1

No

1

0

Is set when the safety controller detects that the diode on EV side is missing.

CS_CurrentPpState

26

3

No

1

0

State of the proximity pin. For fixed cables at CCS2, this value is 0x0: No Cable detected

CS_Contactor1State

33

2

No

1

0

State of contactor 1

CS_Contactor2State

35

2

No

1

0

State of contactor 2

CS_Contactor3State

37

2

No

1

0

State of contactor 3

CS_HV_Ready

38

1

No

1

0

This is the state of the HV ready or State C output. This output is high, if the chargeSOM dont see any errors and CP is at state C. Otherwise it is low.

CS_Estop1ChargingAbort

41

2

No

1

0

No description available

CS_Estop2ChargingAbort

43

2

No

1

0

No description available

CS_Estop3ChargingAbort

45

2

No

1

0

No description available

CS_SafeStateReason

55

8

No

1

0

This signal describes in which module a fault was detected, why the controller went into safeState

Value Descriptions

  • CS_SafeStateActive

    • 0x0 = NormalState

    • 0x1 = SafeState

    • 0x3 = SNA

  • CS_CurrentCpState

    • 0x0 = Unknown

    • 0x1 = A

    • 0x2 = B

    • 0x3 = C

    • 0x4 = D

    • 0x5 = E

    • 0x6 = F

    • 0x7 = Invalid

  • CS_CurrentPpState

    • 0x0 = NoCableDetected

    • 0x1 = 13A

    • 0x2 = 20A

    • 0x3 = 32A

    • 0x4 = 63/70A

    • 0x5 = Type1_Connected

    • 0x6 = Type1_ConnectedButtonPressed

    • 0x7 = Error

  • CS_Contactor1State

    • 0x0 = UNDEFINED

    • 0x1 = OPEN

    • 0x2 = CLOSE

    • 0x3 = NotConfigured

  • CS_Contactor2State

    • 0x0 = UNDEFINED

    • 0x1 = OPEN

    • 0x2 = CLOSE

    • 0x3 = NotConfigured

  • CS_Contactor3State

    • 0x0 = UNDEFINED

    • 0x1 = OPEN

    • 0x2 = CLOSE

    • 0x3 = NotConfigured

  • CS_Estop1ChargingAbort

    • 0x0 = FALSE

    • 0x1 = TRUE

    • 0x3 = NotConfigured

  • CS_Estop2ChargingAbort

    • 0x0 = FALSE

    • 0x1 = TRUE

    • 0x3 = NotConfigured

  • CS_Estop3ChargingAbort

    • 0x0 = FALSE

    • 0x1 = TRUE

    • 0x3 = NotConfigured

  • CS_SafeStateReason

    • 0x0 = NoStop

    • 0x1 = InternalError

    • 0x2 = ComTimeout

    • 0x3 = Temp1_Malfunction

    • 0x4 = Temp2_Malfunction

    • 0x5 = Temp3_Malfunction

    • 0x6 = Temp4_Malfunction

    • 0x7 = Temp1_Overtemp

    • 0x8 = Temp2_Overtemp

    • 0x9 = Temp3_Overtemp

    • 0xA = Temp4_Overtemp

    • 0xB = PP_Malfunction

    • 0xC = CP_Malfunction

    • 0xD = CP_ShortCircuit

    • 0xE = CP_DiodeFault

    • 0xF = HVSW_Malfunction

    • 0x10 = EmergencyInput1

    • 0x11 = EmergencyInput2

    • 0x12 = EmergencyInput3

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<-x|   |   |   |<-----x|<------|
      +---+---+---+---+---+---+---+---+
        |                   +-- CS_SafeStateActive
        +-- CS_PWM_Active
      +---+---+---+---+---+---+---+---+
    1 |------------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- CS_CurrentDutyCycle
      +---+---+---+---+---+---+---+---+
    2 |   |   |   |<-x|<-x|<---------x|
      +---+---+---+---+---+---+---+---+
                    |   |           +-- CS_CurrentCpState
                    |   +-- CS_CpShortCircuit
                    +-- CS_DiodeFault
      +---+---+---+---+---+---+---+---+
    3 |   |   |   |   |   |<---------x|
B     +---+---+---+---+---+---+---+---+
y                                   +-- CS_CurrentPpState
t     +---+---+---+---+---+---+---+---+
e   4 |   |<-x|<-----x|<-----x|<-----x|
      +---+---+---+---+---+---+---+---+
            |       |       |       +-- CS_Contactor1State
            |       |       +-- CS_Contactor2State
            |       +-- CS_Contactor3State
            +-- CS_HV_Ready
      +---+---+---+---+---+---+---+---+
    5 |   |   |<-----x|<-----x|<-----x|
      +---+---+---+---+---+---+---+---+
                    |       |       +-- CS_Estop1ChargingAbort
                    |       +-- CS_Estop2ChargingAbort
                    +-- CS_Estop3ChargingAbort
      +---+---+---+---+---+---+---+---+
    6 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- CS_SafeStateReason
      +---+---+---+---+---+---+---+---+
    7 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+

PT1000State

ID: 0x8 (8)

Length: 8 bytes

Description: This message shall be sent from safety controller to host processor for indicating the state of the connected temperature sensors

Senders: chargeSOM_SafetyController

Table 11: Signals in PT1000State

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

PT1_Temperature

7

14

Big Endian

Yes

0.1

0

°C

Current temperature of PT1000 channel in °C with one decimal digit. 0x1FFF stands for: temp sensor not used.

PT1_ChargingStopped

8

1

No

1

0

Indicates whether this PT1000 channel prevents charging, multiple channel can signal the condition in parallel.

PT1_SelftestFailed

9

1

No

1

0

Indicates whether this PT1000 channel is disturbed, multiple channel can signal the condition in parallel.

PT2_Temperature

23

14

Big Endian

Yes

0.1

0

°C

Current temperature of PT1000 channel in °C with one decimal digit. 0x1FFF stands for: temp sensor not used.

PT2_ChargingStopped

24

1

No

1

0

Indicates whether this PT1000 channel prevents charging, multiple channel can signal the condition in parallel.

PT2_SelftestFailed

25

1

No

1

0

Indicates whether this PT1000 channel is disturbed, multiple channel can signal the condition in parallel.

PT3_Temperature

39

14

Big Endian

Yes

0.1

0

°C

Current temperature of PT1000 channel in °C with one decimal digit. 0x1FFF stands for: temp sensor not used.

PT3_ChargingStopped

40

1

No

1

0

Indicates whether this PT1000 channel prevents charging, multiple channel can signal the condition in parallel.

PT3_SelftestFailed

41

1

No

1

0

Indicates whether this PT1000 channel is disturbed, multiple channel can signal the condition in parallel.

PT4_Temperature

55

14

Big Endian

Yes

0.1

0

°C

Current temperature of PT1000 channel in °C with one decimal digit. 0x1FFF stands for: temp sensor not used.

PT4_ChargingStopped

56

1

No

1

0

Indicates whether this PT1000 channel prevents charging, multiple channel can signal the condition in parallel.

PT4_SelftestFailed

57

1

No

1

0

Indicates whether this PT1000 channel is disturbed, multiple channel can signal the condition in parallel.

Value Descriptions

  • PT1_Temperature

    • 0x1FFF = TempSensorNotUsed

  • PT2_Temperature

    • 0x1FFF = TempSensorNotUsed

  • PT3_Temperature

    • 0x1FFF = TempSensorNotUsed

  • PT4_Temperature

    • 0x1FFF = TempSensorNotUsed

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    1 |----------------------x|<-x|<-x|
      +---+---+---+---+---+---+---+---+
                            |   |   +-- PT1_ChargingStopped
                            |   +-- PT1_SelftestFailed
                            +-- PT1_Temperature
      +---+---+---+---+---+---+---+---+
    2 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    3 |----------------------x|<-x|<-x|
      +---+---+---+---+---+---+---+---+
                            |   |   +-- PT2_ChargingStopped
B                           |   +-- PT2_SelftestFailed
y                           +-- PT2_Temperature
t     +---+---+---+---+---+---+---+---+
e   4 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    5 |----------------------x|<-x|<-x|
      +---+---+---+---+---+---+---+---+
                            |   |   +-- PT3_ChargingStopped
                            |   +-- PT3_SelftestFailed
                            +-- PT3_Temperature
      +---+---+---+---+---+---+---+---+
    6 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    7 |----------------------x|<-x|<-x|
      +---+---+---+---+---+---+---+---+
                            |   |   +-- PT4_ChargingStopped
                            |   +-- PT4_SelftestFailed
                            +-- PT4_Temperature

FirmwareVersion

ID: 0xA (10)

Length: 8 bytes

Description: This message provides information about the type and version of the flashed firmware

Senders: chargeSOM_SafetyController

Table 12: Signals in FirmwareVersion

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

MajorVersion

7

8

No

1

0

Major version of the firmware

MinorVersion

15

8

No

1

0

Minor version of the firmware

BuildVersion

23

8

No

1

0

Build or patch version of the firmware

PlatformType

31

8

No

1

0

This firmware can be used for several products with minor changes in the build process. The platform type describes the used platform

ApplicationType

39

8

No

1

0

The type of firmware. See possible values below

ParameterVersion

47

16

Big Endian

No

1

0

Version of the parameter file

Value Descriptions

  • PlatformType

    • 0x81 = chargeSOM

    • 0x82 = CCY

  • ApplicationType

    • 0x3 = Firmware

    • 0x4 = End Of Line

    • 0x5 = Qualification

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- MajorVersion
      +---+---+---+---+---+---+---+---+
    1 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- MinorVersion
      +---+---+---+---+---+---+---+---+
    2 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- BuildVersion
B     +---+---+---+---+---+---+---+---+
y   3 |<-----------------------------x|
t     +---+---+---+---+---+---+---+---+
e                                   +-- PlatformType
      +---+---+---+---+---+---+---+---+
    4 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- ApplicationType
      +---+---+---+---+---+---+---+---+
    5 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    6 |------------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- ParameterVersion
      +---+---+---+---+---+---+---+---+
    7 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+

GitHash

ID: 0xB (11)

Length: 8 bytes

Description: This message provides information about the GIT hash, written in the firmware

Senders: chargeSOM_SafetyController

Table 13: Signals in GitHash

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

HashSignal

7

64

Big Endian

No

1

0

First 8 byte of the 160 bit (SHA-1) GIT hash

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    1 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    2 |-------------------------------|
      +---+---+---+---+---+---+---+---+
B   3 |-------------------------------|
y     +---+---+---+---+---+---+---+---+
t   4 |-------------------------------|
e     +---+---+---+---+---+---+---+---+
    5 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    6 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    7 |------------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- HashSignal

InquiryPacket

ID: 0xFF (255)

Length: 8 bytes

Description: This packet is used to request a special message from the safety controller

Senders: chargeSOM_HostController, CCY_HostController

Table 14: Signals in InquiryPacket

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

PacketId

7

8

No

1

0

The ID, which message shall be requested. Supported values are described below.

Value Descriptions

  • PacketId

    • 0xA = FirmwareVersion

    • 0xB = GitHash

    • 0x14 = PartNumber1

    • 0x15 = PartNumber2

    • 0x16 = ChipInfo

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- PacketId
      +---+---+---+---+---+---+---+---+
    1 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
B   2 |   |   |   |   |   |   |   |   |
y     +---+---+---+---+---+---+---+---+
t   3 |   |   |   |   |   |   |   |   |
e     +---+---+---+---+---+---+---+---+
    4 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    5 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    6 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    7 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+

PartNumber1

ID: 0x14 (20)

Length: 8 bytes

Description: N/A

Senders: chargeSOM_SafetyController

Table 15: Signals in PartNumber1

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

PartNumber1Signal

7

64

Big Endian

No

1

0

No description available

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    1 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    2 |-------------------------------|
      +---+---+---+---+---+---+---+---+
B   3 |-------------------------------|
y     +---+---+---+---+---+---+---+---+
t   4 |-------------------------------|
e     +---+---+---+---+---+---+---+---+
    5 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    6 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    7 |------------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- PartNumber1Signal

PartNumber2

ID: 0x15 (21)

Length: 8 bytes

Description: N/A

Senders: chargeSOM_SafetyController

Table 16: Signals in PartNumber2

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

PartNumber2Signal

7

64

Big Endian

No

1

0

No description available

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<------------------------------|
      +---+---+---+---+---+---+---+---+
    1 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    2 |-------------------------------|
      +---+---+---+---+---+---+---+---+
B   3 |-------------------------------|
y     +---+---+---+---+---+---+---+---+
t   4 |-------------------------------|
e     +---+---+---+---+---+---+---+---+
    5 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    6 |-------------------------------|
      +---+---+---+---+---+---+---+---+
    7 |------------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- PartNumber2Signal

ChipInfo

ID: 0x16 (22)

Length: 8 bytes

Description: N/A

Senders: chargeSOM_SafetyController

Table 17: Signals in ChipInfo

Name

Start

Length

ByteOrder

Signed

Factor

Offset

Unit

Description

MCUVersion

7

8

No

1

0

No description available

Bitfield Layout

                     Bit

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
    0 |<-----------------------------x|
      +---+---+---+---+---+---+---+---+
                                    +-- MCUVersion
      +---+---+---+---+---+---+---+---+
    1 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
B   2 |   |   |   |   |   |   |   |   |
y     +---+---+---+---+---+---+---+---+
t   3 |   |   |   |   |   |   |   |   |
e     +---+---+---+---+---+---+---+---+
    4 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    5 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    6 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+
    7 |   |   |   |   |   |   |   |   |
      +---+---+---+---+---+---+---+---+

EVerest Board Support Package Module

chargebyte developed a comprehensive hardware abstraction module (HAL, or also called BSP module - board support package) for EVerest charging stack to support the Charge SOM platform. The module is called CbChargeSOMDriver and is available in chargebyte’s public EVerest repository as open-source code: https://github.com/chargebyte/everest-chargebyte/tree/main/modules/CbChargeSOMDriver

This module already implements the required communication protocol to interact with the safety controller.

All Charge SOM boards ship with a Linux system preinstalled on eMMC, which also includes EVerest, the mentioned BSP module and example configuration files.