Charger Interface Board: Firmware
Overview
The general idea of charger is to poll if the charger is plugged in, then request permission from centre console to charge and start charging if allowed. When the battery is full or the charger is unplugged, we stop charging.
Modules:
charger_controller: This module is effectively a wrapper around mcp2515 that manages communication explicitly with the charger. It can be thought of as the ‘driver’ for the charger.
uses mcp2515’s driver to send charging messages
methods:
charger_controller_init
charger_controller_activate
charger_controller_deactivate
Upon receiving a message from the charger, checks for fault bits in the status, and sends a CHARGER_FAULT message with the appropriate fault.
charger_control_pilot: wraps PWM, also converts PWM value to current based on J1772 standard.
Exposes
uint16_t control_pilot_get_current()
to read the PWM of the control pilot pin. Returns a value in deciamps that is the maximum current the charger can provide.
charger_connection_sense: periodically reads the state of the connection_sense pin to determine whether or not the charger is connected. The charger can be unplugged, plugged in with the button pressed, or plugged in with the button released. You need to press the button to unplug the charger (think of it like the handle on a car door - the door can be open, closed with handle pulled, or closed with handle not pulled).
periodically poll the connection sense (CS) pin via ADC to determine state (defined at 500 ms)
upon connecting or disconnecting, transmit
SYSTEM_CAN_MESSAGE_CHARGER_CONNECTED_STATE
with the appropriate exported enum value, and raise aCHARGER_CHARGE_EVENT_STOP/BEGIN
if it’s disconnected or connected respectively.
begin_sequence: handles the sequence of things that need to happen to begin charging
upon processing a
CHARGER_CHARGE_EVENT_BEGIN
event, transmitSYSTEM_CAN_MESSAGE_REQUEST_TO_CHARGE
.Centre console will get the request. If we’re in the appropriate drive state (parking) centre console will send back
SYSTEM_CAN_MESSAGE_ALLOW_CHARGING
.
Upon receiving a
SYSTEM_CAN_MESSAGE_ALLOW_CHARGING
, begin the init sequence:make sure charger is on (transmit
SYSTEM_CAN_MESSAGE_CHARGER_FAULT
if not)Get a pwm reading from control pilot to deduce max current allowed
set relay state then load switch state
enable charging via control pilot
activate charger via
charger_controller_activate
stop_sequence: handles the sequence of things that need to happen to stop charging
Upon processing a
CHARGER_CHARGE_EVENT_STOP
, the sequence will:deactivate the charger via
charger_controller_deactivate
Turn off the control pilot
Turn off the load switch then the relay
battery_monitor: stops charging when the battery is full.
repeatedly receives SYSTEM_CAN_MESSAGE_BATTERY_AGGREGATE_VC
If voltage is over 135 V (defined threshold) will raise a CHARGER_CHARGE_EVENT_STOP event.
Operation Mode:
The BMS sends operating information (Message 1) to charger at fixed interval of 1s. After receiving the message, the charger will work under the Voltage and Current in Message. If the Message is not received within 5s, it will enter into communication error state and stop charging.
CAN Communication
Speed: 250Kbps
Addresses
Messages
Message 1:
This is the message we send to the charger.
Sender: 0xF4 → BMS
Receiver: 0xE5 → Charger Control System
Rest of the Message: 0x1806
Priority: 6
R: 0
DP: 0 (fixed)
PF: 6
Message 2
This is the status message charger sends to us.
Sender: 0xE5 CCS
Receiver: 0x50
CAN Communication
MCP2515 is responsible for sending and receiving CAN messages.
SAE J1772 Standard Notes
J1772 Plug Pinout
Control Pilot PWM
Circuit:
Proximity Pin (PP) or Proximity Detection
page 18 of standard:
Proximity Sense:
GPIO Address: PA7
Design Options:
periodic ADC running always
periodic ADC only activated when the charger is powered (PB1)
Charging Operation:
car should be in park not neutral
we can either be in a undervoltage state, or neutral
we’re also charging from solar
need to have a threshold for opening the solar relays
that threshold is not necessarily the overvoltage fault
cells are 95% charged
whenever solar closed, battery has to be closed
we should always make sure
motor controllers must not be connected
when car’s in parking, mci should disconnect
unless we’re not in an “undervoltage charge state” and we’re in “park” we should be able to charge
there needs to be continuous communication between BMS and the charger to taper the charging.
for MVP we keep it simple “two states”
once charging done:
tell evse by setting the switch
tell charger to stop
open the relay
shouldn’t go to neutral or drive again, unless we pull out the charger
After charging:
bms needs to send a taper message
bms needs to send a fully charged message
talk to liam
Richard’s Notes
Notes on Charger CAN Comm:
Receiving Data:
· Every second from BMS with CAN ID 1806E5F4
· 8 bytes of Voltage and Current requested
· If no valid CAN message, charger stops charging until valid CAN message received
Sending Data:
· Sends CAN message every second with Voltage, Current, and status information
· Source Address - BMS – 2244(0xF4)
Stats & Errors:
· Sends 2 messages, one to BMS and one to CCS
· Output Voltage and Current (2 Bytes each)
· Ex: if Byte = 1234 corresponds to 123.4V
· Status Flags (Byte 5)
· Each status takes a bit (uses 5/8 bits)
Hardware Failure | |
0: Normal | 1: Hardware Failure |
Temperature of Charger | |
0: Normal | 1: Over Temperature Protection |
Input Voltage | |
0: Normal | 1: Wrong Input Votage |
Starting State | |
0: Charger Detects battery voltage and starts charging | 1: Charger stays turned off (to prevent reverse polarity) |
Communication State | |
0: Normal | 1: Communication receive time-out |
Pre-Charging Safety Requirements:
· All Status Flags are 0
· Received valid CAN message from BMS (or CCS) 5 seconds or earlier
Controlled Relays & Hardware