The ZombieVerter VCU Project

[jon volk]

How about a constant 12v supply and leverage some low power mode function on the STM32? Then just use whatever input supply voltages (i.e. key on 12v) on an external wakeup pin? Would cut down on components/board real estate.

[Jack Bauer]

Already does this in the E46 and E65. E46 wakes on ign on. E65 wakes on can from the cas.

[EV_Builder]

Thanks mackoffgrid. Given no one seems to want to get into the details of whats involved in an mcu change then we'll be staying with the f107. As stated this will be 100% opensource so those who don't like what I do can modify it to their own needs.

Ow please lets try todo the best we can with what we know now...
About the software, i regret not haveing responded, you surely deserve your concerns addressed.
But the switch from one cpu to another, in this case, cant be that hard.

If you make it for the STM32F4 device i will convert the VCU application to it, i cant imagine by staying in the cpu familliy and libary system we wil be flooded with work. Offcourse using the native CAN3 port will need code changes since the other usecase used the hardware chip for it. For the rest it stays C++.

How far are we off on the board design? I could start the conversion of the 'vanilla' STM project and figure out what we would be needing to kill it.
On the other hand, there will come a day.... that we will need to pay this debt back.

Johu do you mean 2 VDC pins and then 2 DIODES (and one wired to an IO input)? Or is that to simple?
(now the program knows what is on/off).
Brings me to the next; being able to fuse the outputs seperate from the CPU/inputs would be pretty cool feature...
(connect it too an IO and the application knows it too).

Perhaps only supplying the cpu alone is half the answer already, it could self decide to switch a relais to powerupp the rest of the car.

Which powerdown modes does the STM32Fx have?

[EV_Builder]

Enclosure kit arrived and looks great. Looks like the board mounts to the 4 corners via m3 screws. I'll go ahead and order a few more from the seller to have available when boards arrive. I may end up migrating all the projects to this enclosure and connector as the ME-MX stuff is getting very hard to source and expensive.

Did you recieve the grommet for the caseing itself? I recieved the grommet for the connector only.
(letting a small bath of silicon dry overnight will be a perfect seal anyway).

[Jack Bauer]

Yep I got a casing grommet

[Alibro]

I can't remember if this was mentioned before or not so please forgive if it was but is there an option for reverse? Not everyone will be using a gearbox.

[johu]

Johu do you mean 2 VDC pins and then 2 DIODES (and one wired to an IO input)? Or is that to simple?
(now the program knows what is on/off).
Brings me to the next; being able to fuse the outputs seperate from the CPU/inputs would be pretty cool feature...
(connect it too an IO and the application knows it too).

Which powerdown modes does the STM32Fx have?

Yes that's all there is to it.
I've tried the powerdown modes and they are probably good, but it turned out the various voltage regulators had like 20 mA standby current.

On the BMS we settled for the remote regulator pin. Regulator is woken up by either of the two inputs and is then kept on by the MCU if needed.

You can see how much work is ahead if you replace the "-DSTM32F1" by "-DSTM32F4" in the Makefile. The interface to the various peripherals isn't consistent and some peripherals have not been implemented.

[EV_Builder]

You can see how much work is ahead if you replace the "-DSTM32F1" by "-DSTM32F4" in the Makefile. The interface to the various peripherals isn't consistent and some peripherals have not been implemented.

For the interface to the peripherals we should make our own layer.
In that way all the applications have the same interface to the hardware (if we can) and in that layer the choice is then made to use F1 or F4
(by define for example). peripherals which are not implemented could then be added in that layer. The user doesn't see that.

I will check and see if i end up in a ch*t storm or if i think we should bite the bullet. Lets face it nobody says no to some extra power and 3 can interfaces

[JaniK]

I can't remember if this was mentioned before or not so please forgive if it was but is there an option for reverse? Not everyone will be using a gearbox.

Thanks for asking what I want to know too

It is present something like this for simplicity sake:
"IN1=drive
IN2=reverse"
in GS450H VCU board code allready,
but do not know about LEAF part of Zombieverter though.

On first post in this Zombieverter thread list of features by damien:

"
...
for/rev/neutral control,
...
"

[Jack Bauer]

Which exact f4 part are we talk about:

[JaniK]

I can't remember if this was mentioned before or not so please forgive if it was but is there an option for reverse? Not everyone will be using a gearbox.

Thanks for asking what I want to know too

It is present something like this for simplicity sake:
"IN1=drive
IN2=reverse"
in GS450H VCU board code allready,
but do not know about LEAF part of Zombieverter though.

On first post in this Zombieverter thread list of features by damien:

"
...
for/rev/neutral control,
...
"

I found it, in damiens github, where it should be. (leafinv.cpp)
"insert facepalm emoji"

Direction control part only for the leaf!

Code: Select all

void LeafINV::SetTorque(int8_t gear, int16_t torque)
{
    if(gear==0) final_torque_request=0;//Neutral
    if(gear==32) final_torque_request=torque;//Drive
    if(gear==-32) final_torque_request=torque*-1;;//Reverse

    Param::SetInt(Param::torque,final_torque_request);//post processed final torue value sent to inv to web interface

}

E: it is not completely ready though..

[EV_Builder]

Which exact f4 part are we talk about:

Not fully explored yet, but I guess we want one JCL offers and one with DAC's and minimum 2CAN ports I would suggest.

I will dive into it later today (after work).
What would be a fair budget for the CPU alone? 10bucks? 15?
8?

[johu]

I see quite often in the code something like "x == 32". That is bound to break should we ever decide to use more fixed point digits. It's better portable if you write
x < 0 (for negative test)
x > 0 (for positive)
x == FP_FROMFLT(23) (for value test)

The F107VC also has 2 DACs and 2 CANs. That said, for mysterious reasons the STM32F411VET6 is only $3.70 as opposed to $17 for the F107

[Jack Bauer]

So I'm not at all worried about the price of parts on the board. After all I'll be ripping people off to the max with the kit prices:) Anyway, I am VERY inclined to stick with the F107. My logic being I'm ordering these in 10s from JLC so if we hit a bottle neck a processor upgrade doenst scrap 10k boards. I didn't realise the 107 has dacs...

[EV_Builder]

I see quite often in the code something like "x == 32". That is bound to break should we ever decide to use more fixed point digits. It's better portable if you write
x < 0 (for negative test)
x > 0 (for positive)
x == FP_FROMFLT(23) (for value test)

The F107VC also has 2 DACs and 2 CANs. That said, for mysterious reasons the STM32F411VET6 is only $3.70 as opposed to $17 for the F107

You are right about the comparison but since its a "int8_t" ..
My 2cents would be to use types for gears and states and that type of stuff.

So compare gear == GEAR_DRIVE, GEAR_NEUTRAL,GEAR_REVERSE etc...

[rstevens81]

Prices are all over the place at the moment, and the cost of the stm32 is not really going to put us off!

I think the best course would be to just pick one and regroup in a year when the prices and availability stabilise.

Plus with the 107 and it's dac's Damian has the possibility of macking some tunes on the inverter

[Jack Bauer]

Yep thats the plan. Found the DACS on the f107. Under "Analog". Duuhhh. I'll feed em into a dual audio amp.

[mackoffgrid]

That said, for mysterious reasons the STM32F411VET6 is only $3.70 as opposed to $17 for the F107

Prices are all over the place at the moment,

It's not just prices, more importantly, it's supply.

It's a pity we can't pre-buy parts from JLC to secure stocks.

I'm in the process of designing my BMS (and 12v lithium bms) and I've changed processors for the third time, settling on the stm32L452, figured I'd go low power. (I have 150 cells to monitor - who would of thought I'd end up using ARM M4s for the job) . I ordered 20 of these from Mouser last week - due today. I can report that the bxCan, so far, is identical to the F103/5/7 series.

Regarding selecting which F4/L4 processor, I am generally picking on what is available on the Nucleo boards since STmicro seem to have done a reasonable job in providing variant setups for the entire Nucleo range in their stm32Duino.

For my BMS master where I want dual CAN - I would have used a 105, now I'll be using stm32F446 which I have coming in the same order as above.

I'd love to help with this project, and with F1 to F4 compatibility , but,
I am not familiar with the compiler you're using at the moment. I've been sticking to Arduino and using bare metal programming where I need to.
So I don't think I'm in a position to help you directly at the moment, which you deserve, but as a result of my BMS project, I hope to release an Arduino CAN library (basic) that will work on F103/5/7, F4,L4 - heavily borrowed from exocan library.

[EV_Builder]

So I'm not at all worried about the price of parts on the board. After all I'll be ripping people off to the max with the kit prices:) Anyway, I am VERY inclined to stick with the F107. My logic being I'm ordering these in 10s from JLC so if we hit a bottle neck a processor upgrade doenst scrap 10k boards. I didn't realise the 107 has dacs...

I understand but i honestly cant see why we wouldn't do it... code is c++ its basically one time to convert the project to be compatible and add an extra HAL layer (for the future).

I checked the parts of JCL and found the STM32F446 tempting or the STM32F415 if we want ethernet.

Lets do phase one first, makeing the hardware. In the hardware review we could check if we easily could upgrade in the future.
That way we don't have two hurdles at the same time (software and hardware changes). idea?

For the software part we could start of with a MIM upgrade first to STM32F4 in that way we can experiment and gain confidence.

[EV_Builder]

So I'm not at all worried about the price of parts on the board. After all I'll be ripping people off to the max with the kit prices:) Anyway, I am VERY inclined to stick with the F107. My logic being I'm ordering these in 10s from JLC so if we hit a bottle neck a processor upgrade doenst scrap 10k boards. I didn't realise the 107 has dacs...

I understand but i honestly cant see why we wouldn't do it... code is c++ its basically one time to convert the project to be compatible and add an extra HAL layer (for the future).

I checked the parts of JCL and found the STM32F446 tempting or the STM32F415 if we want ethernet.

Lets do phase one first, makeing the hardware. In the hardware review we could check if we easily could upgrade in the future.
That way we don't have two hurdles at the same time (software and hardware changes). idea?

For the software part we could start of with a MIM upgrade first to STM32F4 in that way we can experiment and gain confidence.

I just read a thread about a nice board.
And if we would go one CPU bigger then that board it would be: STM32G473VBT6
Its a JCL part, its in stock. Costs $10,- has 3x Native CAN's, many timers. PWM signals with dead time etc. it comes from the same series as the STM32F107

We should check the libraries. I do agree this will be a V2 cpu.

[EV_Builder]

Ok, i checked the libraries and the G4 is not very much supported. Saying that i don't think its allot of work plenty of examples to get the hang of it.

Comparison:

[mackoffgrid]

I've not used the "G" series before. They look very interesting, but their CAN is FDCAN whereas the "F" series use BXCAN. Multiple 16 bit ADC looks pretty cool. I wonder if it may be too much of a departure from the F series as an early consideration.

I of course agree with Damien that the F107 (F105V) is perfectly suited, as long as stock is available.

[Jack Bauer]

Alrighty, First full day on the design. Got the f107 and peripherials drawn out. We'll have :
2x HS CAN
1x HS/SW/FT CAN via MCP2562 / NCV7356 / TJA1055
1x LIN optionals master/slave via TJA1020
2x DACs boosted to 12v swing via TDA2822 Audio amp
2x AD5160 digital pots

And had a shot at a pinout. Didn't take long to fill up 56 pins

[Jack Bauer]

Those wishing to support the project could write a library for the AD5160.
Datasheet here : http://www.analog.com/media/en/technica ... AD5160.pdf

[johu]

I have unified the boot loader to work on both 1k and 2k page size devices: viewtopic.php?f=7&t=1587

EDIT: likewise added flash size and page size auto-detection to the two modules in libopeninv that write to flash: CAN and param_save