The ZombieVerter VCU Project

[Kelju]

Is it so that one cannot have messages with the same id on both the powertrain- and vehicle CAN?

[johu]

Is it so that one cannot have messages with the same id on both the powertrain- and vehicle CAN?

Good point. I guess this should be different callback functions. Since powertrain and vehicle CAN may be configured a common handler should be called with the interface number.

Code: Select all

void CommonHandler(int interface, int id, uint32_t data[2])
{
  code...
}

void Can1Handler(int id, uint32_t data[2])
{
  CommonHandler(0, id, data);
}


void Can2Handler(int id, uint32_t data[2])
{
  CommonHandler(1, id, data);
}

[EV_Builder]

Is it so that one cannot have messages with the same id on both the powertrain- and vehicle CAN?

Good point. @Johu why does the callback Influence that? You would think it won't have a clue about ID's...

[johu]

Good point. @Johu why does the callback Influence that? You would think it won't have a clue about ID's...

Because if there are mutual IDs you need to also distinguish which interface it is coming from

[EV_Builder]

Because if there are mutual IDs you need to also distinguish which interface it is coming from

Uhhh yeah that solves an identity problem, but what I have/deal with is no reception of same IDs at all?

[Jack Bauer]

Following some collaboration with Johannes we now have a first official binary release for the vcu : https://github.com/damienmaguire/Stm32- ... ses/latest

Modules tested in this release :

Basic functionality e.g. contactor control, precharge ,throttle,brake etc
External charger control
CAN1,CAN2 and CAN3.
Native Chademo fast charging utilising CAN3
Timed AC charging
BMW E39 module
BMW E46 module
Nissan Leaf inverter module
OpenInverter module
ISA shunt module

NOT tested in this release:
GS450h module. Will be done in coming week or two once GS450h system arrives.
Prius module. As above.
PWM and DAC fuel gauge modules.
Other vehicle modules.

[Jack Bauer]

Testing of the integrated Chademo dc fast charge continues with now 3 brands of station working perfectly.

[kevpatts]

Love it, great work Damien!

[steveknox]

That's amazing, great work.

[johu]

I have done what seems like an enormous commit to the firmware. The goal was to not change functionality at all So I'd appreciate people going out and testing that I haven't broken anything.

So what have I done?

1. I split the CAN hardware driver from the processing logic, i.e. the part that implements things like "can rx xxx yyy"
   The point is to be able to implement the same drive interface for the MCP2515 without code duplication. Also since the VCU doesn't really use dynamic CAN mapping (yet) the pure hardware drivers are more lightweight
2. The CAN mapping itself has been restructured to be more dynamic. It now allows floats as gain factors and offsets between -128..127.
3. It also does not tie a fixed number of items to a CAN message but rather there is a linked list of CAN map items that the messages reference to.
   This would for example allow 64 items within one CAN message where before you were only allowed 8. It also doesn't waste memory for unused items
4. I have moved a lot of code that handles specific CAN messages or registers them with the CAN module into the module that actually uses them.
   Goal is to make the stm32_vcu.cpp more agnostic of the actual device logic

#3 has already been tested in the Tesla charger but all other code has never run on any hardware. So maybe someone with a ZombieVerter on their desk can play around with it.

[paaa]

I have done what seems like an enormous commit to the firmware. The goal was to not change functionality at all So I'd appreciate people going out and testing that I haven't broken anything.

So what have I done?

1. I split the CAN hardware driver from the processing logic, i.e. the part that implements things like "can rx xxx yyy"
   The point is to be able to implement the same drive interface for the MCP2515 without code duplication. Also since the VCU doesn't really use dynamic CAN mapping (yet) the pure hardware drivers are more lightweight
2. The CAN mapping itself has been restructured to be more dynamic. It now allows floats as gain factors and offsets between -128..127.
3. It also does not tie a fixed number of items to a CAN message but rather there is a linked list of CAN map items that the messages reference to.
   This would for example allow 64 items within one CAN message where before you were only allowed 8. It also doesn't waste memory for unused items
4. I have moved a lot of code that handles specific CAN messages or registers them with the CAN module into the module that actually uses them.
   Goal is to make the stm32_vcu.cpp more agnostic of the actual device logic

#3 has already been tested in the Tesla charger but all other code has never run on any hardware. So maybe someone with a ZombieVerter on their desk can play around with it.

Ill gladly give it a spin as soon as im near the car at the weekend.

[Jack Bauer]

Its hiding in there:) 334 miles, 5 hours of blood sweat and some tears, 7 ccs fast charges and we have a GS450h system ready for bench testing....now if I just had a bench....

[Bigpie]

Are you sure there's not a bench in there too?

[paaa]

Just an update , I tested new .bin above, good news is dashboard can is now working for e65 , and webpage is working better. Bad news is inverter doesn't go into inv mode on and doesn't start high pitched whine. Im investigating if its something to do with inverter relay ,but I was working with old code.Pot values checked and pot nom acting as normal with torque value changing. Will have more time a weekend but I suspect its something down to inverter relay pin out put or something similar.

[nkiernan]

Just an update , I tested new .bin above, good news is dashboard can is now working for e65 , and webpage is working better. Bad news is inverter doesn't go into inv mode on and doesn't start high pitched whine. Im investigating if its something to do with inverter relay ,but I was working with old code.Pot values checked and pot nom acting as normal with torque value changing. Will have more time a weekend but I suspect its something down to inverter relay pin out put or something similar.

When you're testing, have a check if the inverter comes on in the webpage (relay comes on) at the 'ignition on' signal and just before the 'start' signal, then turns back off when start signal applied!

[paaa]

Just an update , I tested new .bin above, good news is dashboard can is now working for e65 , and webpage is working better. Bad news is inverter doesn't go into inv mode on and doesn't start high pitched whine. Im investigating if its something to do with inverter relay ,but I was working with old code.Pot values checked and pot nom acting as normal with torque value changing. Will have more time a weekend but I suspect its something down to inverter relay pin out put or something similar.

When you're testing, have a check if the inverter comes on in the webpage (relay comes on) at the 'ignition on' signal and just before the 'start' signal, then turns back off when start signal applied!

Will do I assume it's something like this as first time inverter hasn't made the whine noise yet.

[Jack Bauer]

I have a bench now. And a gs450h system. Also scored a gearbox and inverter from an is300h so these will be coming to a Zombie vcu near you shortly. Next on the agenda is building a dedicated hv junction box with contactors, rig up a dash display and switch panel so all sw and hw functions can be tested on the bench before release.

[Alibro]

Coming together nicely.
You could build a land speed racer on that.

[Jack Bauer]

Picked up a GS450h inverter on yesterday's road trip for the sum of 200 euros. Now ready to start the bench setup. IS300h system due wednesday.

[Jack Bauer]

Is300h system is here.

[Zechy]

Is300h system is here.

[Jack Bauer]

So found one nasty software bug that was stopping the gs450h module from sending a torque request and we have spin :


I'm going to clean this up over the next few days and test in the other cars then do a commit and release and a big long boring video showing how to wire up, test and run the gs450h system. Then is300h fun starts.

[Jack Bauer]

So the situation is the release code here : https://github.com/damienmaguire/Stm32- ... tag/1.00.A
works fine with the gs450h system. Compilation from the source has some major bugs so please use the release binary for now until I fix.

[TheSilverBuick]

How's the supply chain hardware situation on ZombieVerters? I've been sitting on the fence ordering one for a couple month's knowing some critical components were(are?) back ordered and up to the purchaser to source and assemble. Based on my skill set, I'd prefer ordering one with as complete a board as possible.

(I was going to ask on the patreon video, but figured this may be a question other's have as well =) )

[nkiernan]

So the situation is the release code here : https://github.com/damienmaguire/Stm32- ... tag/1.00.A
works fine with the gs450h system. Compilation from the source has some major bugs so please use the release binary for now until I fix.

Loaded up the binary from the link here and just did a quick test, and happy to report the inverter now whines away and gearbox attempts to rotate (PSU trips out on amps so different battery test tomorrow). I did have to bypass the inverter power relay and connect inverter power direct to 12V (and InvStat stayed off in the web interface) but I'll be checking some wiring tomorrow too. InvUDC etc all reporting ok which I hadn't before