damienmaguire/stm32-vcu

A Vehicle Control Unit for Electric Vehicle Conversion Projects based on an STM32F107. Software based on the Openinverter Project.

stm32-vcu

Project based on the OpenInverter System by Johannes Huebner to provide a universal VCU (Vehicle Control Unit) for electric vehicle conversion projects.

Please visit the development thread on the Openinverter Forum for more information : https://openinverter.org/forum/viewtopic.php?f=3&t=1277

Video on progress : https://vimeo.com/506480876

V1.11a On dyno with GS450h / BMW E39 : https://vimeo.com/802405172

V2.00a now available : https://vimeo.com/824494783?share=copy

V2.05a now available.

Features

• Nissan Leaf Gen1/2/3 inverter via CAN
• Nissan Leaf Gen2 PDM (Charger and DCDC)
• Mitsubishi Outlander Support
• Mitsubishi Outlander drivetrain (front and rear motors/inverters) Support
• Modular BMS / SimpBMS Support
• OpenInverter CAN Support
• CCS DC fast charge via BMW i3 LIM
• Chademo DC fast charge
• ISA Shunt / BMW SBOX / VW EBOX supported via CAN
• Lexus GS450H inverter / gearbox via sync serial
• Lexus GS300H inverter / gearbox via sync serial
• Toyota Prius/Yaris/Auris Gen 3 inverters via sync serial
• BMW E46 CAN support
• BMW E39 CAN support
• BMW E65 CAN Support
• BMW E31 CAN Support
• Mid 2000s VAG Can support
• Subaru vehicle support
• Opel Ampera / Chevy Volt 6.5kw cabin heater
• VW LIN based 6.5kw cabin heater
• Elcon charger Support
• OBD2 Can support
• TESLA Gen 2 DCDC Converter Can support

Compiling

You will need the arm-none-eabi toolchain: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads The only external depedencies are libopencm3 and libopeninv. You can download and build this dependency by typing

make get-deps

Now you can compile stm32-vcu by typing

make

Tests

cd tests

Build the tests

make

Run the tests

./test_vcu

And upload it to your board using a JTAG/SWD adapter, the updater.py script or the esp8266 web interface

I use CodeBlocks IDE : https://www.codeblocks.org/

Sept 21 : V1 hardware and firmware from "Master" branch now running in my E46 Touring and E39 vehicles.

March 24 : V1.1 Hardware and V2.05A firmware now running in 3 vehicles :

-BMW E39 with Lexus GS450H Drivetrain, Tesla PCS, ISA Shunt , Chademo Fast Charge

-BMW E46 Touring with Nissan Leaf Gen 1 Drivetrain, Outlander Charger / DCDC, ISA Shunt , CCS Fast Charge

-BMW E31 with Tesla LDU Drivetrain, Tesla DCDC, ISA Shunt , Chademo Fast Charge

All hardware / software is tested in these vehicles before release. More vehicles with different configuration in progress to ensure as much testing as possible.

stm32-vcu's Issues

Feature: Add Support for Outlander PHEV Water Header (Can controlled Version)

Details here https://openinverter.org/wiki/Mitsubishi_Outlander_Water_Heater

Support configuration via CAN SDO

I think it would be useful if the VCU allowed configuration via CAN. There have been several bug fixes for the CAN SDO protocol which prevented it from functioning. Also there have been improvements that allow CAN based tools to download the parameter and spot value database from the device and to accurately version this to prevent conflicts.

Updating the version of libopeninv to commit 73a8bb3631a8e207522dace05a7c246c598988e9 or newer will allow openinverter-can-tool to configure, monitor and log data from the VCU.

Feature: Add support for brake booster pump

Using a vacuum sensor on analogue input and a pump on digital output, when in run mode, read the input value and if under threshold (using a hysteresis value) , enable the output.

brk_out and bms_in conflict with GP_analog1 and MG2_temp

Looks like brk_out and bms_in didn't make the final design. I'm happy to clean it up, but want to confirm they should go away and not move to a new pin.

Brake input isn't connected to the MCU on the Zombieverter V1 schematic

The pinout suggests it is PA15.

Unintended behaviour of Throttle::CalcThrottle in Single Channel Mode

Hello,

I suspect that the ZombieVerter might have unexpected behavior in the Single Channel Mode. This is due to the following:

The function GetUserThrottleCommand reads the analog values of throttle1 and throttle2. This is done with the anain::Get function from the libopeninv. The configuration of the anain class is not conditional on the use of one or two throttle inputs:

Stm32-vcu/include/anain_prj.h

Lines 10 to 11 in 3423052

	ANA_IN_ENTRY(throttle1, GPIOC, 0) \
	ANA_IN_ENTRY(throttle2, GPIOC, 1) \

This means that in any case a value for throttle2 will be read from the GPIOs. If there's nothing connected, this must be treated as an undefined input. Probably it will be 0 because of the external pullup, but it doesn't have to be. One way or another, it should never be used in Single Channel Mode.

In the GetUserThrottleCommand function in line 80, the pot2val variable is set to Throttle::potmax[2] in Dual Channel mode, however it is not changed in Single Channel mode. This means that in Single Channel mode, the GPIO value of what was read from the GPIO (which shouldn't be used in the first place in Single Channel Mode) will be passed to CalcThrottle and most definitely be very different to Throttle::potmax[2].
In any case I'm not sure if line 80 would be a good idea anyways, since in Dual Channel mode, the pot2val variable isn't even the pot2val anymore.

utils::GetUserThrottleCommand:

Stm32-vcu/src/utils.cpp

Lines 49 to 87 in ae9c2a6

	float GetUserThrottleCommand()
	{
	int potval, pot2val;
	bool brake = Param::GetBool(Param::din_brake);
	int potmode = Param::GetInt(Param::potmode);
	potval = AnaIn::throttle1.Get();
	pot2val = AnaIn::throttle2.Get();
	Param::SetInt(Param::pot, potval);
	Param::SetInt(Param::pot2, pot2val);
	/* Error light on implausible value */
	if (!Throttle::CheckAndLimitRange(&potval, 0))
	{
	// DigIo::err_out.Set();
	utils::PostErrorIfRunning(ERR_THROTTLE1);
	return 0;
	}
	bool throt2Res = Throttle::CheckAndLimitRange(&pot2val, 1);
	if (potmode == POTMODE_DUALCHANNEL)
	{
	if (!Throttle::CheckDualThrottle(&potval, pot2val) || !throt2Res)
	{
	// DigIo::err_out.Set();
	utils::PostErrorIfRunning(ERR_THROTTLE1);
	Param::SetInt(Param::potnom, 0);
	return 0;
	}
	pot2val = Throttle::potmax[1]; //make sure we don't attenuate regen
	}
	if (Param::GetInt(Param::dir) == 0)
	return 0;
	return Throttle::CalcThrottle(potval, pot2val, brake);
	}

Now let's see what CalcThrottle does with the pot2val variable that's passed to it:

Throttle::CalcThrottle:

Stm32-vcu/src/throttle.cpp

Lines 97 to 126 in fe50dff

	float Throttle::CalcThrottle(int potval, int pot2val, bool brkpedal)
	{
	float potnom;
	float scaledBrkMax = brkpedal ? brknompedal : regenmax;
	if (pot2val >= potmin[1])
	{
	potnom = (100.0f * (pot2val - potmin[1])) / (potmax[1] - potmin[1]);
	//Never reach 0, because that can spin up the motor
	scaledBrkMax = -0.1f + (scaledBrkMax * potnom) / 100.0f;
	}
	if (brkpedal)
	{
	potnom = scaledBrkMax;
	}
	else
	{
	potnom = potval - potmin[0];
	potnom = ((100.0f + regenTravel) * potnom) / (potmax[0] - potmin[0]);
	potnom -= regenTravel;
	if (potnom < 0)
	{
	potnom = -(potnom * scaledBrkMax / regenTravel);
	}
	}
	return potnom;
	}

In line 102 it checks if potmin[1] is bigger than potmax[1]. This has three issues:

1. We shouldn't use potmin[1] and potmax[1] in Single Channel Mode, because they could be set to arbitrary values.
2. pot2val is set to potmax[1] in the previous function, so the expected behavior is, that the if condition is always true.
3. It is possible however, that potmax[1] is smaller than potmin[1], if the second potentiometer is inverted to the first one. This is checked in the Throttle::CheckDualThrottle function, but not in this function.

Regarding issue 2: scaledBrkMax is set to a constant value, since pot2val was set to a constant (potmax[1]) in GetUserThrottleCommand. But this only applies in Dual Channel mode!

This will subsequently have issues on the regen behaviour.

There is a small additional bug in line 76: in case of an error with throttle 2, the error message will say throttle 1 as well.

There is a huge flaw:

Stm32-vcu/src/throttle.cpp

Line 121 in fe50dff

potnom = -(potnom * scaledBrkMax / regenTravel);

regenTravel is allowed to be set to 0, so this can be a division by zero, leading to +inf on the float!

Stm32-vcu/src/throttle.cpp

Line 100 in fe50dff

float scaledBrkMax = brkpedal ? brknompedal : regenmax;

One more thing: The variable "brknompedal" is not set anywhere. This means that it's probably set to 0 (default), but it's not specified.
This means scaledBrkMax will be set to -0.1f, since potnom is multiplied by zero:

Stm32-vcu/src/throttle.cpp

Lines 102 to 107 in fe50dff

	if (pot2val >= potmin[1])
	{
	potnom = (100.0f * (pot2val - potmin[1])) / (potmax[1] - potmin[1]);
	//Never reach 0, because that can spin up the motor
	scaledBrkMax = -0.1f + (scaledBrkMax * potnom) / 100.0f;
	}

---

My proposed fixes are:

1. Stm32-vcu/include/param_prj.h

   Lines 307 to 311 in 7e766f7

   	enum _potmodes
   	{
   	POTMODE_REGENADJ = 0,
   	POTMODE_DUALCHANNEL,
   	};

   
   Change POTMODE_REGENADJ to POTMODE_SINGLECHANNEL.

2. Remove the pot2val = potmax[1]; from GetUserThrottleCommand. This can not be intended behaviour.

3. Change the identity of CalcThrottle to Throttle::CalcThrottle(potval, brake). Since the plausibility of pot2val has been checked, we don't need to send it to CalcThrottle (and we shouldn't, regarding issue 1 and 3).

4. Add a range check for regenTravel to avoid uninteded behaviour (division by zero).

5. Either discard brknompedal or set it to a value.

---

I will prepare a pull request, but I can't test it at the moment.

Add Soft IO to Vehicle Class

To allow more flexible installations on Canbus vehicles, allow ability for Vehicle Class to send status signals replacing the DIN_Start/Fwd/Rev etc.

This method, along with the dynamic pin assignment should allow more flexibility in using CAN signals.
For the purpose of the initial update, the vehicle signal can be OR'd similar to existing canio signal.

Reason for request:
Currently the OI inverter implementation requires DigIn signals, as they are simply mapped direct to the OI CAN interface.
Attempted to replicate similar E65 type canbus shifter, however that implementation seems to duplicate and complicate things more.
Simpler solution would be to allow Vehicle Class to Mimic DigIn signals to allow similar function.
Basically at the moment there is no way to control OI other than hardwiring signals into Zombie.

In the future it will likely allow us to over-assign the DigIO supplementing with CAN based signals. and repurposing existing IO that is unused due to signals being sourced on the CAN network.

*I am aware that CANio can be possibly configured for this purpose, but the main intent is to have zombie connect to OI, while keeping the Vehicle CAN separate.

Simp BMS Charge current scale factor

I am using the simp BMS option in the VCU. The BMS_ChargeLim value in the web interface seems wrong. Looking in the simpbms.cpp, the chargeCurrentLimit is divided by 1000. The simp_BMS datasheet states that this value is scaled by 10.

AC Charging with Leaf PDM not functioning because 0x1D4 is not being sent in charge mode

PDM goes to fail-safe, because 1D4 is not being sent in charge mode.

Add 1D4 to PDM code, so it gets sent when in charge mode.
I have this working in my fork https://github.com/Romukeisari/Stm32-vcu-LeafLBC/blob/master/src/NissanPDM.cpp
Background: https://openinverter.org/forum/viewtopic.php?p=70232#p70232

charger.h/.cpp are missing

Wanted to try this out and found that charger.cpp and charger.h are referenced, but missing. Commented out for now. Thanks for this!

Feature: Add Support for AC compressors generally and the Outlander Compressor Specifically

https://openinverter.org/wiki/Mitsubishi_Outlander_AC_Compressor for details

Feature: Add support to stream can messages directly to SavvyCan

It would be cool to be able to stream the canbus messages to SavvyCan. This can be done with OVMS. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/can/src/canformat_gvret.cpp

https://github.com/collin80/ESP32RET

Update codebase to include GigaDevices GD32F107 routines and Merge GD_Zombie branch

At present the GD_Zombie branch has fallen way behind.
Creating this issue to track status and progress of efforts to incorporate the GD32F107 back into the project and prevent it from becoming Vaporware.

It was mentioned on the Dev forum in this post that "The GD based boards will not run the firmware intended for the ST boards without the modifications that Johannes (@jsphuebner) Identified."

I suggest we start by documenting what those modification suggestions proposed by @jsphuebner on the forum were here where they belong with the code and revisioning system.

Improvement: Add a framework to support various Heartbeat can messages

Most HV components require a heartbeat type message, 0x285 for example with Outlander stuff. The current code setup will duplicate this message if multiple components are used.

E.G. Outlander Charger and Outlander Inverter. Both modules send out 0x285. Ideally the VCU would send this only once to each required can bus at the required intervals.

List and Overview of Parameters and Spot Values

I am looking to see if there is a list of Parameters and Spot Values that are available in the STM32-VCU for configuration and debugging.

On the OI wiki page for Zombie I cannot really find anything. If there is a list somewhere or someone creates one let me know and I will contribute what I learned from digging through the code.