Tesla Model 3 Charge Port Controller Standalone Development

[mdrobnak]

Erm. No, standard GPIO pin as output, not sure what I was thinking. The rest of that list is sane. Might be just a standard GPIO for input depending on voltage thresholds as well.

-Matt

[Jack Bauer]

No probs:)

[Jack Bauer]

Got the components where I want them. Now its just tracking. I'm going to wire up my EU CCS charge port over the weekend and grab some can.

[Jack Bauer]

Ok folks here it is. Included a 10 pin tag connect full jtag. Please review then we can get some ordered from JLC.

[mdrobnak]

Today was hectic, will try and review in a few moments or by early morning tomorrow my time..

[mdrobnak]

Overall looks good. I'm just going to jot down some thoughts under here. I may ask some stupid questions. Please be patient.

We're substituting the STLink USB passthrough for a dedicated USB, yes? What are the LEDs for on the USB connection? Mini USB is good.
CAN connections look good. I need to try PA11/12 again. I tried that before I had the timing right on the F4 board and got nowhere.
Power supply is interesting - I don't think I've ever seen 0.1uF next to a 470 uF cap. What's the purpose of that?
What's the EEPROM actually connected to? SCL and SDA are connected to the CPU with a 4.7kOhm pull-up to 3.3V?

Latch output works fine with high side drive straight off the CPU on the Nucleo board (so 3.3V), I was driving it with the SimpBMS' 5V output, so your 5V output should work great there.

Proximity voltage is 12V I think, so good call on the digital inputs being 12V capable.

Fault line worked fine on a standard digital input on my F7 board. So, to ADC or to GPIO? I'm also not sure of the RC value on the input. They have the schematics here - https://www.st.com/resource/en/schemati ... ns_sch.zip - Board is MB1137 / Nucleo-F767ZI - I'm using PG2 for the fault input and PG3 for the latch output.

8MHz and 32,768Hz crystals look great.

The layout I can't say much as I've done single layer PCBs but never more than that. Silkscreen layer looks good.

So I don't think there are any changes, subject to your thoughts based on my feedback. (If read it right, the ADC input can also be used in digital mode as well - but may not work as well with the resistor...hence I am deferring to you on this.)

Bed time now.

-Matt

[clanger9]

Looks good.
You can get nasty spikes on the proximity line. Is it worth putting a clamping diodes on the 12V inputs, or is that not necessary?

[mdrobnak]

Ok, here's a thing:
https://github.com/mdrobnak/cpcontrol-redacted

Right now it's got almost no comments since I stripped them out with a sed script. But I restored main.rs as nothing in there was specific to the work I've done.

For now I'll keep this updated with what I'm doing to give an idea of what the code looks like. And hopefully inspire some others to learn Rust. Or for people to point out my dumb mistakes.

I'm going to go double-check the checksum algorithm (which, incidentally for one ID doesn't actually matter - in my last example it was very wrong (I was off by one in the data count (0.. data-2 instead of data-1), so it didn't add the counter in..so it stayed static... anyway, I fixed that, but I want to double check I did it right. After that, I'm going to try and get some latch / proximity state data.

My Model 3 freaked out the other day with a BMS error, which, while unsettling it seemed to have recovered from it. I'll still set an appointment once I'm done with this stuff.

-Matt

[mdrobnak]

I did some measurements last night (relative to chassis ground):
* Pin 4 - Proximity Out from CP ECU goes to Rear drive inverter (Drive Inhibit I assume)
* Pin 5 - Latch Enable Input to CP ECU from "HV Battery"
* Pin 6 - Fault Line Output from CP ECU to "HV Battery"

1. Doors closed, trunk open, charge port door idle
- Pin 4 - 2.29V
- Pin 5 - 4.06V
- Pin 6 - 4.24V

2. Doors closed, trunk open, charge port door open
- Pin 4 - 2.29V
- Pin 5 - 4.06V
- Pin 6 - 4.24V

3. Doors closed, trunk open, charging
- Pin 4 - mV range
- Pin 5 - mv Range
- Pin 6 - 4.24V

4. Doors closed, trunk open, charging *interrupted*
- Button press restores values to idle / open.
- Within a few seconds charging resumes
- Values return to charging numbers after the relay has turned on.

Looks like the proximity In on the inverter is a pull-down, as unloaded that puts out 11.X volts on the bench for me.

Confirmed that the checksum calculation is correct for 2 of the three IDs using it. The third one I think I messed up the 0/1 modulus values, so I swapped them and will re-test that later.

The RTC stuff is more complicated than I'd like (ironically if we used an outside RTC like this: https://crates.io/crates/ds323x I'd be done. Since we're not, that'll take a little longer. Lots of Binary Coded Decimal (BCD) values in registers, stuff that needs to be enabled, proxy variables...it's a little bit of a mess.

Also, searching for Rust RTC stuff I hit on this: https://blog.tonari.no/why-we-love-rust - which shows features, and how I plan on getting it to work with STM32F7 Nucleo, F4 Nucleo, and production boards.

Action items:
* Verify checksum on last ID
* Set latch status to similar as to what is above and see how that affects behavior
* Update comments in code to denote items I would like to redact vs don't care, and publish updated code with more comments.
* Work on generalizing hardware-specific code to use features
* Update state machine to operate like stock does with respect to interrupted charging

[mdrobnak]

* Checksum is good.
* Latch untested but updated.
* Comments updated, more commented code is live on github.
* Didn't do much of that.
* Didn't do any of that.


I _did_ find some RTC examples by accident for the STM32F1 and F3. Between both of them, and examples for the DS232X above, I got something to compile...and then crash.
Running it trough gdb and stepping through (after disabling the 1k/sec timer interrupt LOL!) shows that get_time returns all zeros, which it is not supposed to. So something is probably looking at the wrong bits somewhere. The heavy lifting is done, just need to read over the docs and massage everything to work together.

Also tried out "cargo clippy" against the code - which for those who remember from Microsoft Office, "I think you're trying to do this"...it offers extremely opinionated critiques of your code. So while it didn't generate warnings, my code is far from 'standard.'

Tomorrow:
* Check latch
* Try and generalize code and get running on F4 board again. I tried to do this tonight and went down the RTC rabbithole...
* Verify J1772 logic

[Jack Bauer]

I can put an rtc chip on there if we need.

[johu]

Heres the code I use for the F1:

Code: Select all

   //Base clock is HSE/128 = 8MHz/128 = 62.5kHz
   //62.5kHz / (624 + 1) = 100Hz
   rtc_auto_awake(RCC_HSE, 624); //10ms tick

Which expands to:

Code: Select all

void rtc_auto_awake(enum rcc_osc clock_source, uint32_t prescale_val)
{
	uint32_t reg32;

	/* Enable power and backup interface clocks. */
	rcc_periph_clock_enable(RCC_PWR);
	rcc_periph_clock_enable(RCC_BKP);

	reg32 = rcc_rtc_clock_enabled_flag();

	if (reg32 != 0) {
		rtc_awake_from_standby();
	} else {
		rtc_awake_from_off(clock_source);
		rtc_set_prescale_val(prescale_val);
	}
}

From here: https://github.com/jsphuebner/libopencm ... 2/f1/rtc.c

Maybe it helps.

[mdrobnak]

Heres the code I use for the F1:

...

From here: https://github.com/jsphuebner/libopencm ... 2/f1/rtc.c

Maybe it helps.

Thanks johu, useful for an overall view to make sure it's going about the same thing.

I can put an rtc chip on there if we need.

Let me play with it a little before waving a white flag. Worst case we can use the DS2321M. What STM32 based boards do you have? I'll try and rig something up to send to you for use with your data capture attempts.

-Matt

[mdrobnak]

No RTC miracles yet, however, we do have liftoff with making it compile for both boards (untested as of the moment, but will do so along with the latch tomorrow:

Code: Select all

mdrobnak@dell-cp2-md-ubuntu:~/redact$ cargo build --features=nucleo767zi
warning: file found to be present in multiple build targets: /home/mdrobnak/redact/src/main.rs
    Updating git repository `https://github.com/mdrobnak/stm32f7xx-hal.git`
   Compiling stm32f7xx-hal v0.2.0 (https://github.com/mdrobnak/stm32f7xx-hal.git#1ff6c666)
   Compiling cpcontrol v0.1.0 (/home/mdrobnak/redact)
    Finished dev [unoptimized + debuginfo] target(s) in 12.70s
mdrobnak@dell-cp2-md-ubuntu:~/redact$ cargo build --features=f4board
warning: file found to be present in multiple build targets: /home/mdrobnak/redact/src/main.rs
   Compiling stm32f4 v0.11.0
   Compiling stm32f7 v0.11.0
   Compiling rand_core v0.5.1
   Compiling cpcontrol v0.1.0 (/home/mdrobnak/redact)
   Compiling embedded-dma v0.1.2
   Compiling stm32f4xx-hal v0.8.3 (https://github.com/mdrobnak/stm32f4xx-hal.git#845f1902)
    Finished dev [unoptimized + debuginfo] target(s) in 24.43s
mdrobnak@dell-cp2-md-ubuntu:~/redact$ ls -l target/thumbv7em-none-eabihf/debug/cpcontrol-f?
-rwxrwxr-x 2 mdrobnak mdrobnak 2860132 Oct 22 23:30 target/thumbv7em-none-eabihf/debug/cpcontrol-f4
-rwxrwxr-x 2 mdrobnak mdrobnak 3238296 Oct 22 23:29 target/thumbv7em-none-eabihf/debug/cpcontrol-f7

The updated code is on github, including the broken RTC implementation for the f7-hal crate.

It's much nicer now as I was able to remove a hal reference from pretty much every tile:

Code: Select all

mdrobnak@dell-cp2-md-ubuntu:~/redact$ git diff src/two_fifty_ms_loop.rs
diff --git a/src/two_fifty_ms_loop.rs b/src/two_fifty_ms_loop.rs
index 76d73a0..f4500e7 100644
--- a/src/two_fifty_ms_loop.rs
+++ b/src/two_fifty_ms_loop.rs
@@ -1,7 +1,6 @@
 #![deny(warnings)]
-extern crate stm32f7xx_hal as hal;
 use crate::types::HVCAN;
-use hal::can::{BaseID, DataFrame, ID};
+use crate::types::{BaseID, DataFrame, ID};
 use heapless::consts::*;
 use heapless::String;

Bed time.

-Matt

[mdrobnak]

Meant to send something earlier but never hit the button. Twice. Whoops!

It turns out the timing on the F4 board is quite poor because it was not using the High Speed External crystal. In this case, this comes from the ST-Link board, but it makes a HUGE difference in terms of timing stability. With some wonderful help from the rust-embedded folk on the Internet, that part is solved.

Latch behavior was checked, no change really. But fault line status and latch control do work.

Both the F7 and F4 boards are set to 180 MHz, and a 45 MHz peripheral clock, so now I don't have multiple CAN timings to deal with. I can do without the 36MHz.

I also think the RTC code requires the HSE to be enabled, so that's probably why it was broken on the F7 board. Nope, LSE needs to be enabled. Punting again for now.

To be clear - STM32F446 board and STM32F767 board both run the code now, at the correct CAN speed, and make the CP ECU happy. Auto-start works as desired.

I looked over the J1772 stuff last night, and it looked OK at first glance.

What I did end up getting done today is all of the hardware initialization code is out of main.rs now. There are three targets:
nucleo767zi (should be f767zi, oops. will fix later)
nucleof446re
production

There are now aliases to build each:
cargo bf4, bf7, bprod to "build" for a given target
cargo rf4, rf7, rprod to "run" for a given target (build then load into GDB and flash).

Some of the connectors for the ISA shunt arrived today, I'll probably start on some of that mid next-week.

What I'm going to attempt to do after dinner:
* Verify J1772 state machine ordering
* Update state machine to operate like stock does with respect to interrupted charging
* Figure out how to enable LSE or something else suggested by people in the rust channel. Not ready to use up more power for something already in the chip

-Matt

[Jack Bauer]

Overall looks good. I'm just going to jot down some thoughts under here. I may ask some stupid questions. Please be patient.

We're substituting the STLink USB passthrough for a dedicated USB, yes? What are the LEDs for on the USB connection? Mini USB is good.
CAN connections look good. I need to try PA11/12 again. I tried that before I had the timing right on the F4 board and got nowhere.
Power supply is interesting - I don't think I've ever seen 0.1uF next to a 470 uF cap. What's the purpose of that?
What's the EEPROM actually connected to? SCL and SDA are connected to the CPU with a 4.7kOhm pull-up to 3.3V?

Latch output works fine with high side drive straight off the CPU on the Nucleo board (so 3.3V), I was driving it with the SimpBMS' 5V output, so your 5V output should work great there.

Proximity voltage is 12V I think, so good call on the digital inputs being 12V capable.

Fault line worked fine on a standard digital input on my F7 board. So, to ADC or to GPIO? I'm also not sure of the RC value on the input. They have the schematics here - https://www.st.com/resource/en/schemati ... ns_sch.zip - Board is MB1137 / Nucleo-F767ZI - I'm using PG2 for the fault input and PG3 for the latch output.

8MHz and 32,768Hz crystals look great.

The layout I can't say much as I've done single layer PCBs but never more than that. Silkscreen layer looks good.

So I don't think there are any changes, subject to your thoughts based on my feedback. (If read it right, the ADC input can also be used in digital mode as well - but may not work as well with the resistor...hence I am deferring to you on this.)

Bed time now.

-Matt

Sorry I've been slacking off on this project:)
1)The 0.1uf beside the big electrolytic is standard power supply design. Big caps are very poor at eliminating hf noise so you drop in a small ceramic beside them to help out.

2)So do we need to change the i/o pins for fault and latch or are we ok there?

3)I can add an external RTC chip if required.

So subject to those issues I can generate the placement and bom and fire them off to JLCPCB and get some boards. I'm also going to rig up my port on the bench and get some can captures from both the US and EU CCS ecus.

[mdrobnak]

rtc.png (7.32 KiB) Viewed 6422 times

RTC is working.
It's a pain in the butt to work with due to the nature of what you're doing with it. But By comparing to a ST example rtc calendar project, I was able to determine what was not quite right. You have to ensure certain clocks are enabled, and certain registers have a write protect value which you have to undo, modify the settings, and turn back on. Then it all works.

So, that's going. Yay.

Re 2) I'm not sure, As the board sits, it works fine. But I'm not sure what the signal levels would look like with your input setup. That's why I wondered what your thought was on ADC vs GPIO digital edge detection.

As I found, definitely need that 8MHz crystal, so that's good. Also the 32768 Hz one is good if the board is put into low power mode, that'll be kept alive on the battery backup for RTC.

To reiterate other questions:
We're substituting the STLink USB passthrough for a dedicated USB, yes? What are the LEDs for on the USB connection? Mini USB is good.

CAN connections look good. I need to try PA11/12 again. I tried that before I had the timing right on the F4 board and got nowhere.

What's the EEPROM actually connected to? SCL and SDA are connected to the CPU with a 4.7kOhm pull-up to 3.3V?


It's late. Bed time for real. Got a lot done today though!

-Matt

[Jack Bauer]

To reiterate other questions:
We're substituting the STLink USB passthrough for a dedicated USB, yes? What are the LEDs for on the USB connection? Mini USB is good.

CAN connections look good. I need to try PA11/12 again. I tried that before I had the timing right on the F4 board and got nowhere.

What's the EEPROM actually connected to? SCL and SDA are connected to the CPU with a 4.7kOhm pull-up to 3.3V?


It's late. Bed time for real. Got a lot done today though!

-Matt

Sorry I missed that. Yeah I put a serial to usb on Serial 1. The leds are just tx , rx indicators for the serial.

SDA and SCL are on PB7 and PB6. I got those pins from using CubeMX as the I2c pins. Is that ok?


Finally got the setup on the bench and shot some log files.

https://github.com/damienmaguire/Tesla- ... Controller

[mdrobnak]

Sorry I missed that. Yeah I put a serial to usb on Serial 1. The leds are just tx , rx indicators for the serial.

SDA and SCL are on PB7 and PB6. I got those pins from using CubeMX as the I2c pins. Is that ok?


Finally got the setup on the bench and shot some log files.

https://github.com/damienmaguire/Tesla- ... Controller

No worries. Ok, activity LEDs, got it.

If CubeMX spit it out, it's probably fine? Just looked at the alternate function table for the F4 processor and indeed PB6 is "I2C1_SCL" and PB7 is "I2C1_SDA" for AF4. I ask because this is how the schematic shows it:

and thus I was confused and wanted to make sure there were no errors which would lead to issues with the layout. Better to double check before actually getting it manufactured was my thought.

I'll take a look at the logs probably Monday.

Today's action items:
* See if I can fix the RTC driver in a nicer way than my 2 AM hack.
* Fix F4 RTC driver (which is basically a copy - they're all very similar except for the low power units which have a different RTC available apparently)
* Drive my BMWs
* Deal with some career stuff

-Matt

[mdrobnak]

https://github.com/damienmaguire/Tesla- ... Controller

I couldn't help but peek.

Somebody's being funny Data length + 30 is all I get, eh?

A few observations:
0x5FE is different on the EU unit.
You're missing your ground, and thus your data in 0x21D is wrong. Put that chassis ground wire on the same ground as your power supply for now.
0x33D, 0x77D, 0x7DD are new.

Bonus:
0x432 0 to 0x30 counted in 2s will keep it alive.

-Matt

[Jack Bauer]

Cool. I'll give that a shot tomorrow. Does anyone have the part number for the 10 pin connector on the cp ecu?

[mdrobnak]

I only have the TE / Amp part number, which is unobtanium. No idea what Model 3 harness has it unfortunately.
EDIT! Mouser has stock now!!! https://www.te.com/usa-en/product-1452349-1.html
Edit 2: If we can find the mating connector we can make useful cables

The model3dbc github (https://github.com/joshwardell/model3dbc) will decode some of that data, but not the other interesting pieces on the HV side. Very few have done capture of that side.

-Matt

[mdrobnak]

LOL oops did I hit the solve button?

Well, I _did_ solve the RTC on both the F7 and F4 board. So that's going. F7 code is in the repo:
https://github.com/mdrobnak/stm32f7xx-hal

F4 code is nearly exactly the same.

Code: Select all

mdrobnak@dell-cp2-md-ubuntu:~/vcs/git/mdrobnak-stm32f4xx-hal/src$ diff ../../mdrobnak-stm32f7xx-hal/src/rtc.rs rtc.rs 
440c440
<     pwr.cr1.modify(|_, w| {
---
>     pwr.cr.modify(|_, w| {

which, incidentally was one of the changes I had to do to fix it on the f7 hal. So seems the F7 hal is the odd one out.

F4 code will up a little later, but really, that's the only diff (you still need to declare the RTC module, update the RCC for the backup domain control register, etc).

-Matt

[mdrobnak]

Heres the code I use for the F1:

Code: Select all

   //Base clock is HSE/128 = 8MHz/128 = 62.5kHz
   //62.5kHz / (624 + 1) = 100Hz
   rtc_auto_awake(RCC_HSE, 624); //10ms tick

Which expands to:

Code: Select all

void rtc_auto_awake(enum rcc_osc clock_source, uint32_t prescale_val)
{
	uint32_t reg32;

	/* Enable power and backup interface clocks. */
	rcc_periph_clock_enable(RCC_PWR);
	rcc_periph_clock_enable(RCC_BKP);

	reg32 = rcc_rtc_clock_enabled_flag();

	if (reg32 != 0) {
		rtc_awake_from_standby();
	} else {
		rtc_awake_from_off(clock_source);
		rtc_set_prescale_val(prescale_val);
	}
}

From here: https://github.com/jsphuebner/libopencm ... 2/f1/rtc.c

Maybe it helps.

The RTC init code did end up being very similar as seen here - https://github.com/mdrobnak/stm32f7xx-h ... 066dc499c5

Code: Select all

        // Steps:
        // Enable PWR and DBP
        // Enable LSE (if needed)
        // Enable RTC Clock
        // Disable Write Protect
        // Enter Init
        // Configure 24 hour format
        // Set prescalers
        // Exit Init
        // Enable write protect
 

Using the LSE clock as a base will eventually allow us to put the controller into sleep. But I'm not there yet

F4 HAL update is uploaded.

ToDo:
* Update state machine to operate like stock does with respect to interrupted charging
* Verify J1772 logic
* Find mating socket for the connector I posted earlier
* Find one of these eeprom chips to mess with
* See how Isaac configured the ISA shunt in his SimpleISA library, as we probably want to standardize on data formats

-Matt

[mdrobnak]

Looks good.
You can get nasty spikes on the proximity line. Is it worth putting a clamping diodes on the 12V inputs, or is that not necessary?

This is generated by the CP ECU, not directly from the input, as far as I can tell. I think it's used for drive away protection.

As far as other items, I think I got the state machine right.
I also am handling door open / close requests now. I had the command being processed, but never looked for the feedback that it was going, and thus never changed the state.
I think J1772 logic is correct, I'll have to play back some CAN data and see what it does.

I looked briefly at the SimpleISA library. I think I understand what it is trying to do in the init function.
Looks like there may be an error:

Code: Select all

	for(int i=0;i<9;i++)

The datasheet says 0-7...
Reconfigured to be little-endian data
Cyclical
Rates are slower and slower as you go down the line. (I guess this is to ensure you don't hit into the 1000 msg/sec max)

Tomorrow:
Test state machine handling of interrupted charge.
See if door open / close requests work better.
Find connectors and EEPROM chip.
Review logs when the Model 3 freaked out with the 'wrong software version' ECU was connected and validate or disprove some of my data assumptions.