The ZombieVerter VCU Project

[Jack Bauer]

She's alive:)

New branch on the repo:
https://github.com/damienmaguire/Stm32- ... /GD_Zombie

[Bryson]

Excellent! When you’re ready for testers/contributors, shout. My connector and enclosure are already on the way.

[Alibro]

Looking neat.

[Jack Bauer]

Pinout and description done. Also picked up on 2 unrouted connections.

[Jack Bauer]

Ah the joys of GigaDevices. As some of you may have already figured out I'm using the GD32F107VCT6 on the vcu. Its very close to being an STM32F107VCT6 but not quite...

Johannes had figured out one problem so got code running on the vcu and bench tested the following :
Digital inputs
Analog inputs
Toyota hybrid coms
Pwm timers(tim1 so far)
Usart3 (wifi)

Then hit a brick wall with CAN. No tx and no rx. Tx was a damien special. Not using remapped pins in the setup routine. Only took a day for brains here to relalise that... anyway now we have tx on both CAN channels. Yay....but still no rx..

Another day and about 25 emails to Johannes later I blunder my way to the receive routine and find that GD handle the CAN fifos differently to ST and thus the libopencm3 routine was only executing once. I bodged a work around and we have can rx.

Pushing this to the repo now so folks have something to test with. Attaching the GDF1 refference manual as only took an hour to download ...

[Jack Bauer]

On the subject of Arm, bout time I fired this baby up:)

[Alibro]

On the subject of Arm, bout time I fired this baby up:)

LOL, a very long time ago I repaired them for a local education board.
Unfortunately I was a bit rubbish at it. Mostly swapping chips to see what would happen.

[JaniK]

On the subject of Arm, bout time I fired this baby up:)

LOL, a very long time ago I repaired them for a local education board.
Unfortunately I was a bit rubbish at it. Mostly swapping chips to see what would happen.

Some auto repair shops just change parts that may get the car running, so business as usual

[Jack Bauer]

First batch of boards on their way to beta testers:)

[Dilbert]

First batch of boards on their way to beta testers:)

Thanks, one just landed here, I will look at how the Toyota protocol will run on the giga device and see if the same approach from the stn32 will work or needs updates.

[Jack Bauer]

So just to make a list of whats needed from the software side :

-Driver for the LIN bus using the TJA1020. I think Johannes has done something on this so I may just rip that off.

- Driver for CAN 3 using the MCP25625 on SPI2. Not fitted to current boards as out of stock at jlc but I have 50 on the way from Microchip so will fit to the next batch.

-Implement the PWM outputs.

-Implement the 2 DAC outputs.

-Driver for the two digital potentiometers AD5160 chips on SPI3.

Some of this I can muddle through myself but as always any help apreciated especially on the software side:)

[johu]

The DAC code intended for Tesla resolver is here: https://github.com/jsphuebner/stm32-car ... hwinit.cpp . Should lend itself well to any application.

[Dilbert]

On 3 of the items below, would it be possible just to map these to parameters, which can then be manipulated locally in the firmware, or the web interface or even mapped onto the CAN bus if needed?

-Implement the PWM outputs.
-Implement the 2 DAC outputs.
-Driver for the two digital potentiometers AD5160 chips on SPI3.

So if the firmware read the params every 50-100mS and just updated the physical output device, if there has been any change in the parameter value.

[EV_Builder]

That's more like remote IO functionality. But what Damien means is the core code in itself to write to an output with pwm functionality. I think we should build a smaller remote IO device (extension style) but that's on my list of whishes. Easy to distribute in the car and can be centrally commanded is my idea.

[EV_Builder]

Very cool VCU guys. Starts to look like a pro-build.

Defenitly recommend to buy.

Small tweaks with my Chinese housing and connector. There is only one case grommet, connector surrounded. I don't have the grommet for the lid so to say.

The board is very good for a first runs. Because it fits. For the sake of tolerances I think that:
- watching it from the back, connector down, the right hole pattern plus mounting hole should be like 0.6mm to the left.
- watching it component side, connectors to the top, my right lower hole is 1mm of to the right. So my threads of the bolt touch the board.

But it all fits and can be made fit perfectly so for a first run it couldn't be better.

[Jack Bauer]

Thanks for the feedback:)

[EV_Builder]

Thanks for the feedback:)

You are more then welcome .

[Jack Bauer]

Little bit of overlap here from the i3 ccs thread. This is a BMW i3 EDME. Basically their version of a VCU that control the drivetrain, battery , cooling etc.

Here is the BMW blurb :
EDME: Electrical Digital Motor Electronics

The EDME control unit acts as the master control unit and coordinator for the primary functions of the drive control.

Before a drive torque is implemented, the EDME must be checked to see if the driving readiness has been produced.

The EDME queries if all the subsystems of the electrical drive control function trouble-free, which is a requirement for allocating the drive torque. The EDME control unit regards the available electrical power for the electric motor, which is primarily determined by the state of the high-voltage battery. Via the corresponding Bus telegrams, the SME control unit communicates the state to the EDME control unit.

As a result of these checks, the EDME determines if and in what scope the drive torque can be provided. In the event of fault states or restricted availability, the EDME outputs a Check Control message on the instrument cluster.

The EDME control unit is supplied with terminal 30B and terminal 15 wake-up.

The EDME control unit is connected to the data buses of the FlexRay, PT-CAN and PT-CAN2.
The following components are connected to the Electrical Digital Motor Electronics (EDME):

Accelerator pedal module
Intelligent battery sensor via the LIN bus
Front electric fan
Electric fan of engine compartment
2 temperature sensor in the rear engine compartment (for Range extender OE only)
Electric coolant pump
Radiator blind drive (active air-flap control) via LIN bus
Shutoff-capable expansion valve

The EDME control unit contains among other things the logic when the parking lock should be engaged or disengaged. Via the PT-CAN, the EDME control unit transmits the corresponding commands to the electrical machine electronics (EME).

It behaves similar with the drive positions "R" and "D". Here too, the EDME control unit calculates the function logic. The electrical machine electronics (EME) is responsible for the execution, to for example activate the electrical machine in accordance with reversing or drive.

[Jack Bauer]

So,anyone interested in writing a LIM class for the VCU or just adding to the charger class?

[EV_Builder]

On 3 of the items below, would it be possible just to map these to parameters, which can then be manipulated locally in the firmware, or the web interface or even mapped onto the CAN bus if needed?

-Implement the PWM outputs.
-Implement the 2 DAC outputs.
-Driver for the two digital potentiometers AD5160 chips on SPI3.

So if the firmware read the params every 50-100mS and just updated the physical output device, if there has been any change in the parameter value.

I'm planning to make a small IO gateway/slave/assistant BMS etc.. over CANBus. So it will expand the usecases it will do what you wrote.
CANBus in and out and you control IO. Ideally to use with hardware in the trunk or frunk for example. Saves wires. I just need to learn designspark first....

[Jack Bauer]

Well this is fun. Getting the LIM class added to the master branch for testing in the E46. I mean its only 350kw of potential charger power and I never do things like put signed values in unsigned variables or mistake || for | ....

Seriously though folks a little help on this would be great... Even just a look over for stupid programming mistakes. I'll push what I've done so far to the repo.

On another note :

static const int MAX_USER_MESSAGES = 10;

Seriously Johannes!

[Dilbert]

I wouldn't mind helping out, but i'm also thinking about how to make this generic for the various different chargers that people are using etc...

See attached my first attempt at drawing up a state diagram for the system including a charger.

[Jack Bauer]

On a specific note can someone please help me with this :

Code: Select all

I_Batt=(Param::GetInt(Param::idc)+819.2)*10; //This crashes the stm32
I_Batt=(Param::GetInt(Param::idc)+819)*10; //This works but with a slightly wrong value.

[angusmf]

On a specific note can someone please help me with this :

Code: Select all

I_Batt=(Param::GetInt(Param::idc)+819.2)*10; //This crashes the stm32
I_Batt=(Param::GetInt(Param::idc)+819)*10; //This works but with a slightly wrong value.

I'm 25 years rusty on C++ but, try casting the result of getting the param as a float (or get it as a float value if you can???). Something like ... =((float)Param::GetInt(Param::idc)...
The way you're trying to do it, you'll lose the floating point part of 819.2 anyway, because apparently if you just add a float and and int, the float gets converted to an int implicitly instead of the other way. Casting will maybe fix your error but will also preserve the floating point.

[davefiddes]

I think if you use the following in the i3LIMClass::Send10msMessages() you should get better accuracy using the fixed point macros.

Code: Select all

   V_Batt=FP_TOINT(FP_MUL(Param::Get(Param::udc),10));
   V_Batt2=FP_TOINT(FP_DIV(Param::Get(Param::udc),4));
   I_Batt=FP_TOINT(FP_MUL(Param::Get(Param::idc)+FP_FROMFLT(819.2),10));
   SOC_Local=FP_TOINT(FP_MUL(Param::Get(Param::SOC),10));

I've only compile tested this so it comes with a health warning. The basic idea with the fixed point macros is:

• add and substract values using regular + and - C operators
• multiply and divide use the FP_MUL(a,b) for a*b and FP_DIV(a,b) for a/b. Don't use the C / and * operators.
• All C constants with a decimal point (e..g 3.1415) are floats. You can use these provided you convert to fixed point s32fp type with the FP_FROMFLT() macro
• To get the integer portion of a fixed point value us FP_TOINT().

Hope this helps.