Tesla Model 3 Charge Port Controller Standalone Development

Development and discussion of fast charging systems eg Chademo , CCS etc
Post Reply
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

As discussed in my BMW 330 thread, Damien and myself will work on producing a combination of hardware (Damien) and software (me) to control the CP ECU outside of a Tesla. Due to firmware differences, it is highly recommended to get a unit that was in a 2019 or newer vehicle, as 2018 US vehicles may not support the CHAdeMO adapter.

What does the CP ECU do?
The Charge Port ECU is the interface between a AC or DC charging station and the rest the vehicle. The CP ECU uses data from the BMS to communicate limits to the charging station for fast chargers, send VIN numbers to Tesla Superchargers, and tell AC sources when to turn power on and off in conjunction with the charger in the car.

What are the goals of this project?
Reading over the SimpBMS documentation, I think the correct output from this is a Charge Enable / AC Present signal. The rest of the design ideas I'm copying from my thread (here):

* Write code in a logical way, keeping thing as simple as possible, organized and attempt to catch unhandled scenarios.
* Keep the CP ECU happy.
* Provide Charge Enable signal when plugged in and ready to start charging (ie so SimpBMS can turn on the charger).
* Optionally provide contactor control for DC fast charge.
* DC Fast Charge via CHAdeMO adapter initially, hopefully CCS for EU units as well.
* RTC + battery to support scheduled charging.
* Support saving of configuration parameters.
* Simple / Advanced mode - Simple being Tesla SWCAN / J1772 AC only, Advanced handling contactors to switch between AC/DC.

ToDo:
* IVT-S integration to read voltages - In progress
* SimpBMS integration to read voltages
* EEPROM settings - In progress
* CHAdeMO adapter tests (I think done, but not 100% certain)

State of the Word as of 2021-01-30:
IVT-S tested on the CHAdeMO EVSE code, and looks to be fine. I'll add this in here soon. Working on the EEPROM, but I'm not familar with I2C, so this is slow going.

State of the World as of 2021-01-23:
CHAdeMO session logged on my Model 3, and it looks like there's nothing more to do on this end for a 96S NMC battery pack. Need to test CHAdeMO max voltage setting, but should work for mid voltage setups (350-430V). IVT-S library is coming along, I should be able to read values from a stock-configuration shunt, that will be tested soon.

State of the World as of 2021-01-09:
Voltage control is still not right, unclear what is wrong here. There are some CAN related fixes in progress with the code to try and handle it more efficiently.

State of the World as of 2020-12-16:
CHAdeMO adapter is working! Working on voltage control, current control is working.

State of the World as of 2020-12-02:
Moved software to use RTIC which is a scheduling framework in Rust. Working well, no more timeouts, and consistent timings. CAN driver timeout optimized to not give false alerts. Verified it wasn't just driver by going back to old code with new settings, still had timeout issues. Migrating to RTIC was the right thing to do.

State of the World as of 2020-11-24:
Did some initial CHAdeMO adapter tests. With 'baseline' firmware, it works to the point of where it will stay in standby. I don't have the proper setup created to test further yet. Older firmware US reports unsupported EVSE. Therefore it is recommended to get a unit from a 2019+ car (noted above now).

State of the World as of 2020-11-23:
Fault line reading still ignored. However, latch voltage control and CAN messages are sync'd, fixing an error. Older firmware US, and EU now working. Newer firmware works, but requires non-backwards-compatible changes to enable. Older messages don't break medium term firmware, but do break new firmware. Need to add configuration items to enable modified messages. Working on getting app CRC to match to a list of known values to switch to the new style.

State of the World as of 2020-11-16:
Latch control is working, fault line reading is implemented but currently ignored. Initialization takes a few seconds but is consistent and works. As a result of stability, the touch sensor (inductive door sensor) is working as expected now. Unfortunately no additional ECU support as of yet, working on EU support.

State of the World as of 2020-10-21:
Charging auto-start works now. Latch control being tested and fault line reading implemented. Created a utilities module with a common checksum routine. Fixed issue in said routine. Renamed some variables to be better (like hv_can instead of control_can). Disallowed any warnings in all files. Released redacted version of code on github.

State of the World as of 2020-10-12:
First draft of code written in Rust. Running on STM32F7 processor. Code is in similar state to 2020-09-25, as there have been no major logic changes yet, only porting of the code. Serial console improved with last 4 activity items with uptime timestamp, not just the most recent. Code has no warnings, and only 1 unsafe block that is used during initialization to turn on the TIM2 timer interrupt. Plenty of room for refactoring and optimization, but manual charge does work as expected.

State of the World as of 2020-09-25:
Code is written in C++, using little C++isms except for sed 's/struct/class' for the most part, and using the OO-wrapper on the FlexCAN library from Collin Kidder. Code is being built in Sloeber for Teensy 3.2 (SimpBMS board), which is Eclipse + 'magic' to make Arduino stuff work...but I can make it build via Makefile too. No .ino files (that is what the Sloeber magic part is for, handling .ino files), but still making use of the Arduino core library functions such as Serial.write().
Init code for CP ECU is weak. It definitely gets upset in certain situations. Having the door open makes it happy. :: shrug ::
State machine for Insert cable -> start charge not there yet. Insert cable -> idle -> start charge via serial command is working.
Serial console code is OK but too scattered. I should be able to rewrite things to pass in the needed data to the console.

Code will be rewritten in Rust for the STM32. The opinionated nature of the language, plus memory safety items, plus speed, leads me down this path.

This thread will track progress.

-Matt
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

I'll rough out a hardware design soon. STM32F105 ok ? It has two can controllers. I'd like to dedicate one to the CP ecu and one for external services.
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

Hmm. Given the Teensy 3.2 is a Cortex M4, maybe? I wish there was the embedded equivalent of "top" to see the utilization of the processor. But assuming the CAN stuff is up to snuff, that should be sufficient, yes. We're averaging 650 messages/sec across the different timeframes.

There are three pins of note from the CP ECU:
Latch - Needs to be fed 5V. Unclear if it's always 5V. One of my tests on my car says no, but I need to redo that test perhaps.
Fault - Useful information perhaps?
Proximity - Not sure what to do with this yet, I'm not currently using it.

At some point the ECU does go into 'sleep' mode. So I assume with your choice you're looking for a lower powered CPU as in theory it'll be always connected like the SimpBMS et al, as you may want to charge the car at any given time...

Edit: On a related note, I have my development environment set up on Ubuntu 20.04, and thankfully Crossover runs the almost-latest version of Vehicle Spy, so I can at least do my analysis in there without having to reboot into Windows. I like SavvyCAN, but the UI is hard for me, and one of the really nice features of Vehicle Spy is highlighting changed bytes between messages.

-Matt
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Well, we can use any micro in the JLCPCB catalog:)
https://jlcpcb.com/parts
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

There's a F4 processor in the basic library that might do fine...

So it turns out the CAN library returns 0 if no nodes ack the message, as well. I had nothing but the Teensy and the CP ECU and I woke up to all 0s indicating no messages being sent. I unplugged the CP ECU overnight. Plugged in the CP ECU power and it all resumed nicely.

I'm gathering some J1772 charging data now. Haven't done that with any logging before.

-Matt
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Ok so I'm roughing this out based on an STM32F405RGT6 64 pin part.

-Housed in 32 pin modice enclosure like all my vcu designs.

-2 x CAN. One for CP ECU one for external

-3 x low side drivers

-2 x push pull 12v drivers

-2 x 12v digital inputs

-2 x 5v analog inputs

-USB onboard

-JTAG via Tag connect header

-SWD via 2.54mm 4 pin header

-256k EEPROM

What am I missing ... :)
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

Jack Bauer wrote: Mon Sep 28, 2020 9:48 am Ok so I'm roughing this out based on an STM32F405RGT6 64 pin part.

-Housed in 32 pin modice enclosure like all my vcu designs.

-2 x CAN. One for CP ECU one for external

-3 x low side drivers

-2 x push pull 12v drivers

-2 x 12v digital inputs

-2 x 5v analog inputs

-USB onboard

-JTAG via Tag connect header

-SWD via 2.54mm 4 pin header

-256k EEPROM

What am I missing ... :)
Most of that looks great. :)

256k EEPROM is more than enough. We could probably put a USB flashing program in that amount of space! :D

What is the logic level thresholds for the 12V digital inputs? On my Motec I'm used to being able to dictate thresholds, rising/falling, and hysteresis, so doing this by hand is...interesting.

My counts so far are:
The proximity signal is 12V. (Input from CP ECU)
Fault voltage is 4.X volts, but the SimpBMS pulls it down to like 1.6V, which I'm guessing the input is low impedance. (Input from CP ECU)
We need to be able to switch on/off or generate a 5Vish signal for the latch enable. (Output to CP ECU)
Charge Enable signal for whatever is controlling the actual charger (Output to other device)

For the DC Fast charge part, we need to control contactors. But for the US people, we need to control contactors for anything other than the simple "AC only" mode. (I guess I theory we could allow a DC only mode too, but that's all software.) So we'd need... 4 contactors for single phase AC or DC. We probably want to support both economized and non-economized ones. Can we simply low-side PWM @ 100% duty for economized ones? My assumption on the non-economized ones is to do 100% duty for a few seconds, then ramp down to a hold duty cycle.

Battery slot for RTC for scheduled charging, please.

So by my inexperienced thought process, I'd say we need one more low side driver for contactor number 4 and the battery slot. That's all I think we're missing at the moment.

It's nice to be doing what I went to school for - Computer Engineering instead of Systems Administration, but I'm definitely a little over my head due to lack of experience here - so feel free to tell me I'm an idiot where necessary. :)

-Matt
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Sounds good to me. Schematic on the way:)
I'm going to need a hacksaw
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Quick look inside the CP ecus for both US and EU CCS. EU on the right (larger board and micro).

Main micro on the US board seems to be : spc5605bm but a quick search reveals nothing.

On the EU board it is :SPC56EC70L7
https://www.st.com/en/automotive-microc ... c70l7.html
Attachments
2020-09-29 14.32.27.jpg
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

Nice. Now it's fairly obvious the differences in the two. Looks like a potentially more powerful CPU on the EU one. Also, wow those specs..FlexRay, 6 CAN... :)

"Nexus 1 on all devices" but "Secured device boot mode", so who knows what a debugging interface would show. If we can get a firmware dump I can run it through IDA as I have the PowerPC decompiler. :)

For now will keep trying to refine what I've got. I know handle pushing the button on the handle while the relay is enabled correctly, so that's something.

Re 5605:
http://www.nxp.com/docs/pcn_attachments ... Report.pdf
Don't think they meant for that to show up.
https://www.nxp.com/docs/en/data-sheet/MPC5607B.pdf - Datasheet

-Matt
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

Well, I tried to get it to compile on the STM32F07 and...
I'm using Collin Kidder's FlexCAN library on the Teensy, but I am not sure what to use for the Nucleo board. I tried installing the STM32duino core, but I think I have to basically write the equivalent functions if I don't want to rewrite all my Can0.write() references. :)I did figure out how to set up two targets, and use things like ifdef for the targets:

Code: Select all

#ifndef _CPControl_H_
#define _CPControl_H_
#include "Arduino.h"
//add your includes for the project CPControl here
#ifdef ARDUINO_TEENSY32
#include <FlexCAN.h>
#endif
#ifdef ARDUINO_NUCLEO_F767ZI
#endif
On the bright side:
terminal_screenshot.png
it's been up for almost 48 hours without any issues on the Teensy (with a nice blue solid LED on the port). I rearranged the data, and the update frequencies. I need to swap some positioning around, but basically only the bottom three rows are updated often - every 1 second for the Init / State / Fault row, and every 10 ms for the bottom two rows. The entire screen refreshes every 4 seconds. It shouldn't say Proximity Idle for the state. Need to work on the state machine more.

-Matt

Edit: Man, even though I'd have to write a small wrapper to get the OO stuff going, it's a lot more straightforward than the Rust stuff. I thought it was further along, but I'm going to give it a go still.... Also picked up a Nucleo STM32F4 board for a more representative target compared to where we want in the end.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Ok so finally here is a first cut at the schematic.
Added in the battery and extra driver.
Programming via swd. Can add jtag if necessary?
USB on USART1
WiFi on USART2
Attachments
CCS_M3_VCU_V1 - Schematic.pdf
(207.33 KiB) Downloaded 314 times
I'm going to need a hacksaw
jon volk
Posts: 572
Joined: Wed Apr 10, 2019 7:47 pm
Location: Connecticut
Been thanked: 2 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by jon volk »

mdrobnak wrote: Thu Oct 01, 2020 4:40 am Well, I tried to get it to compile on the STM32F07 and...
I'm using Collin Kidder's FlexCAN library on the Teensy, but I am not sure what to use for the Nucleo board. I tried installing the STM32duino core, but I think I have to basically write the equivalent functions if I don't want to rewrite all my Can0.write() references. :)I did figure out how to set up two targets, and use things like ifdef for the targets:

Code: Select all

#ifndef _CPControl_H_
#define _CPControl_H_
#include "Arduino.h"
//add your includes for the project CPControl here
#ifdef ARDUINO_TEENSY32
#include <FlexCAN.h>
#endif
#ifdef ARDUINO_NUCLEO_F767ZI
#endif
On the bright side:
terminal_screenshot.png

it's been up for almost 48 hours without any issues on the Teensy (with a nice blue solid LED on the port). I rearranged the data, and the update frequencies. I need to swap some positioning around, but basically only the bottom three rows are updated often - every 1 second for the Init / State / Fault row, and every 10 ms for the bottom two rows. The entire screen refreshes every 4 seconds. It shouldn't say Proximity Idle for the state. Need to work on the state machine more.

-Matt

Edit: Man, even though I'd have to write a small wrapper to get the OO stuff going, it's a lot more straightforward than the Rust stuff. I thought it was further along, but I'm going to give it a go still.... Also picked up a Nucleo STM32F4 board for a more representative target compared to where we want in the end.
Is an NXP micro from a Teensy 3.x available from JLC? I believe the only real magic in the Teensy is the external usb bootloader. If programming can be done through a jtag, I assume a hex file compiled for Teensy would work just fine that way.

*EDIT* The teensy3.5 micro is on there. MK64FX512VLL12
Formerly 92 E30 BMW Cabrio with Tesla power
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

jon volk wrote: Fri Oct 02, 2020 3:05 pm Is an NXP micro from a Teensy 3.x available from JLC? I believe the only real magic in the Teensy is the external usb bootloader. If programming can be done through a jtag, I assume a hex file compiled for Teensy would work just fine that way.

*EDIT* The teensy3.5 micro is on there. MK64FX512VLL12
That's probably true, but I think the 3.2 micro is slightly underpowered anyway.

As of now I can manipulate LEDs and I've got a way to print to the serial port in Rust. In the grand scheme of things, the amount of code is still way less than with the Arudino support library backing things. There will probably be a bit more setup code, but I think overall it'll be pretty good.

I appreciate things like this:
compiler_warnings.png
The code to make the example run is:

Code: Select all

#![deny(unsafe_code)]
//#![deny(warnings)]
#![no_main]
#![no_std]

extern crate panic_halt;

use core::fmt::Write;
use nb::block;

use cortex_m_rt::entry;
use stm32f7xx_hal::{
    delay::Delay,
    pac,
    prelude::*,
    serial::{self, Serial},
};
macro_rules! uprint {
    ($serial:expr, $($arg:tt)*) => {
        $serial.write_fmt(format_args!($($arg)*)).ok()
    };
}

macro_rules! uprintln {
    ($serial:expr, $fmt:expr) => {
        uprint!($serial, concat!($fmt, "\n"))
    };
    ($serial:expr, $fmt:expr, $($arg:tt)*) => {
        uprint!($serial, concat!($fmt, "\n"), $($arg)*)
    };
}

#[entry]
fn main() -> ! {
    let p = pac::Peripherals::take().unwrap();
    let cp = cortex_m::Peripherals::take().unwrap();

    let rcc = p.RCC.constrain();
    let clocks = rcc.cfgr.sysclk(216.mhz()).freeze();

    let gpiod = p.GPIOD.split();

    let tx = gpiod.pd8.into_alternate_af7();
    let rx = gpiod.pd9.into_alternate_af7();

    let serial = Serial::new(
        p.USART3,
        (tx, rx),
        clocks,
        serial::Config {
            baud_rate: 115_200.bps(),
            oversampling: serial::Oversampling::By16,
            character_match: None,
        },
    );

    // Get delay provider
    let mut delay = Delay::new(cp.SYST, clocks);

    let (mut tx, mut rx) = serial.split();

    loop {
        uprintln!(tx, "Hello there, the answer is {} ", 40 + 2);
        delay.delay_ms(500u16);
    }
}
You'll note I commented out the deny warnings part - usually it won't even let you run it if you have warnings. They want you to write clean, safe code.
Most of this is setup code, and overall will be a small portion of code. The syntax of certain things seem weird, like the

Code: Select all

fn main() -> ! {
part which basically means 'this program never ends, make sure of it'. It'll yell at you if you forget to put in a never-ending loop. The 'optimized' version of this code is 6kB. So that is fine by me. I found a library to do CAN transmission, and hope to be sending packets by the end of the day. For now, I need to take care of one my other cars.
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

Jack Bauer wrote: Fri Oct 02, 2020 9:31 am Ok so finally here is a first cut at the schematic.
Added in the battery and extra driver.
Programming via swd. Can add jtag if necessary?
USB on USART1
WiFi on USART2
First glance looks good, but as mentioned, definitely a hardware design `newb` so I'll let others chime in here.
Is SWD enough to do the whole gdb remote debug thing? That's how I'm programming the Nucelo right now. (I think yes as SWD is single-wire-debug, right?)

-Matt
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

I'll put in a full jtag just in case using a tag connect : https://www.tag-connect.com/

pcb layout commencing:)
Attachments
2020-10-03 10.09.21.jpg
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

Jack Bauer wrote: Sat Oct 03, 2020 8:48 am I'll put in a full jtag just in case using a tag connect : https://www.tag-connect.com/

pcb layout commencing:)
Nice, ok that seems reasonable.

Rust's embedded ecosystem is...'in progress'. :-D I found this: https://github.com/jonlamb-gh/oxcc which is a Rust version of Open Source Car Control. It's actually written for the board I have, which is one of the reasons I picked it. However, the particular versions of some of the libraries it uses are very different now. Thus, the CAN driver which was written 2 years ago, doesn't work. That said, If you install the nightly compiler (which enables you to turn on / off certain language features, or build against an earlier standard of the language) it builds...and runs! So I'm staring at a board that is furiously blinking away the green LED and I can see packets in SavvyCAN.

So now, I get to modify what's here to do more of what I want, and then try and port the relevant bits to the current state of the world. (There is a Hardware Abstraction Layer and a device-specific layer that need modifying...)

I tried earlier today to go at it from the opposite end and just port the changes forward...and without more context it was just a bit too daunting. I got the 10ms loop + serial console mostly working, but without CAN it would be dead in the water...So now we continue. :)

Edit: I've got the counter going at least. In a convoluted way. LOL.
Also, learned something:
!!! WARNING !!!
panicked at 'attempt to add with overflow', src/main.rs:216:9
While this is perfectly valid in C:

Code: Select all

int counter =  0;
counter += 1;
counter &= 0xFF;
If you say

Code: Select all

counter: u8 = 0;
counter += 1;
counter &= 0xFF;
You get a panic if you do the dumb thing like I did and intentionally wrap the counter. Oops. I remembered reading about that, but forgot until I changed the code slightly and it went beserk! :D
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

On the Rust side:
I could swear I posted this last night, but I guess I only did it on Facebook.


At this point I have a partial debug console and 2 CAN messages being sent out. The code I'm working with was definitely written by someone experienced with Rust, as I don't understand about 25% of it :-D

Steps moving forward:
1. Hack my stuff into this.
2. Decompose what it is doing.
3. Update device layer component: stm32f767 device crate with the stm32f7x7 device crate that is now maintained in the stm32-rs project. Repeat for the Hardware Abstraction Layer (HAL) crate as well.
4. Continue development goals.

These are the links I've found most useful so far:
1. The board I have (via the OxCC project) - https://github.com/jonlamb-gh/oxcc-nucleo-f767zi
2. Awesome Embedded Rust - https://github.com/rust-embedded/awesome-embedded-rust - A state-of-the-world page.
3. The Rust Language - https://doc.rust-lang.org/book/title-page.html
4. https://github.com/mcuby/rust-stm32f429 ... rc/main.rs helped me figure out how to set up a timer to keep track of uptime.

There's definitely more (I've got way too many tabs open), but that's a good starting point. Note any modifications to the device / HAL crates I'll definitely put up on github.


On the design side:
Something I forgot about - so we tell the charger when to start but how do we know when to stop?
Certainly for things like DC fast charge, we need things like battery voltage. So I'm going to assume we're going to have either the ISA shunt, or a SimpBMS available to get actual voltage. As mentioned, trying not to overlap functionality too much with already existing devices - ideally we don't want to have to configure the same information in multiple spots.

-Matt
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

I have successfully ported the CAN driver over, and is now sending out a single message using a lot less code / abstractions. :)

The Nucleo-F446RE arrived today as well. There seems to be items missing from the stm32f4xxx-hal as well. Given my efforts today, that should be pretty easy to get going tomorrow. I expect to have ported the code over in some form or another by Friday.

Correction: Moved back over to the bigger board for a minute, and now I have two messages sending. :D

Time for bed now, however.

-Matt
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

I made some silly assumptions in the code with respect to pins. I have serial console now on the STM32F4. Still no CAN, however. Turns out the driver is doing bit timing directly, and 180 != 216 MHz. :)
Alas, that's not the only issue. I had to try one of the alternate set of pins and it's finally producing _something_.

I will say this, I greatly, greatly apprecaite being able to do this:

Can_driver.speed = CAN_500KBITS;

because you can't do that in reality. For goodness sake, there's an entire website dedicated to it: http://www.bittiming.can-wiki.info/

So here's where I ended up:


I _finally_ have something coming out of the F446. But it seems like the phase is inverted compared to the F7 processor. Which I'm assuming does not play nice with the CAN transceiver.
Funny thing is I can't even get the STMCube code to work for the F4. So, I'm at a bit of a loss.

The M3 took more time than I wanted to give it, still not done with emissions test stuff for that.

I hope to fix the F4 tomorrow, but in either case, I'm going to start fleshing out the transmit stuff more to at least bring it closer to parity with the existing C code.
-Matt

Edit: As promised, here's the port of the driver for the F7 at least: https://github.com/mdrobnak/stm32f7xx-h ... ae24a2fba0
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Excellent. Will have prototype hardware from JLC in about 2 weeks.
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

So it turns out that my calculation was off-by-one, and now we have liftoff:


Both boards are working. Now I will start figuring out how to pass the data around like I did with the C program. Then I'll hook it up and give it a whirl. :)
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

All the sending IDs are implemented, and I've go the absolute basics for CAN receive implemented. So tomorrow I'll work on that. So my original "I'll get it going by Friday" wasn't exactly right, but I never said what getting it going meant. :D

Also, last 4 activity items:
Console1.png
-Matt
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by mdrobnak »

It's not perfect, but I'm pretty happy for how well it worked for the first time being connected to the CP ECU:


Next items:
* State machine fix from "Stop Charge" back to correct place depending on what is the cause for stopping.
* Review logs of J1772 charge to ensure the state machine flows correctly for that case.
* Review voltages of latch and proximity pins under various scenarios
* Review ADC docs so I can get the actual state of the fault line voltage.
* Review DAC docs so I can appropriately control latch and proximity pins.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Tesla Model 3 Charge Port Controller Standalone Development

Post by Jack Bauer »

Excellent. So do we need a DAC output?
I'm going to need a hacksaw
Post Reply