ZombieVerter VCU Support

[EV_Builder]

Regards answering question I do my best but my time and energy is super limited right now.

Yeah sure tell me, I know; Full time job, family and a car to build.

Thank u for your effort.

[Domt177]

Anyone know whether the zombieverter vcu is compatible with the 160kw leaf e+ inverter, not sure whether it’s considered gen3 or not

[paaa]

As far as I know it has even used with the 80kw and 110kw versions so far , but the 160 share the same can besides the higher torque request so I would imagine its easy to implement as only a small change required to scaling

[Jack Bauer]

That's correct. The current Leaf Gen1 menu option will work all the inverters but torque will be limited to the Gen1 values until I get to write the necessary code or someone contributes.

[EV_Builder]

I made a DIGITAL SPI POT Class for the VCU project.

Don't know how to get this into GitHub and if you don't already have it or not coudn't find it just found a sweep tester routine...

Then:

In the top section of the main file i followed the convention of using pointers to the instantiated objects.

Code: Select all

static digpot* objpot1;
static digpot* objpot2;

In the main() but after the IO's are assigned, so after function : ConfigureVariantIO();

Code: Select all

    //instantiate the potmeter objects
    digpot pot1(SPI3, DigIo::pot1cs);
    digpot pot2(SPI3, DigIo::pot2cs);

    objpot1 = &pot1;
    objpot2 = &pot2;    

Some where in a task...

Code: Select all

 
 static uint8_t pot1val=0;
 static uint8_t pot2val=0; 
 
  objpot1->SetPotStep(pot1val);
  objpot2->SetPotStep(pot2val);
  
  pot1val+=1;   
  pot2val+=1;
  

Add to the stm_vcu.h

Code: Select all

#include "digpot.h"

editted void spi3_setup() heavily to my standard..

Code: Select all

void spi3_setup()   //spi3 used for digi pots (fuel gauge etc)
{
   gpio_primary_remap(AFIO_MAPR_SWJ_CFG_JTAG_OFF_SW_ON, AFIO_MAPR_SPI3_REMAP);
   
   gpio_set_mode(GPIOC, GPIO_MODE_OUTPUT_50_MHZ, GPIO_CNF_OUTPUT_ALTFN_PUSHPULL, GPIO12 | GPIO10);//MOSI , CLK
   gpio_set_mode(GPIOC, GPIO_MODE_INPUT, GPIO_CNF_INPUT_FLOAT, GPIO11);//MISO

   /* Reset SPI, SPI_CR1 register cleared, SPI is disabled */
   spi_reset(SPI3);

   SPI3_I2SCFGR = 0;

   spi_init_master(SPI3, SPI_CR1_BAUDRATE_FPCLK_DIV_32, SPI_CR1_CPOL_CLK_TO_0_WHEN_IDLE,
                  SPI_CR1_CPHA_CLK_TRANSITION_1, SPI_CR1_DFF_8BIT, SPI_CR1_MSBFIRST);

   spi_set_bidirectional_transmit_only_mode(SPI3);

   spi_enable_software_slave_management(SPI3);
   spi_set_nss_high(SPI3);

   spi_enable(SPI3);
}

add to the make file

Code: Select all

OBJSL		= $(BINARY).o hwinit.o stm32scheduler.o params.o terminal.o terminal_prj.o[b] digpot.o[/b]

I commited this libary to my github fork.
(no clue how i can make pullrequest for damien yet)

https://github.com/EV-Builder/Stm32-vcu

[collin80]

I commited this libary to my github fork.
(no clue how i can make pullrequest for damien yet)

https://github.com/EV-Builder/Stm32-vcu

Go to your repo that linked to above. While there, go to the pull requests tab. Then click the "New Pull Request" button. This will automatically try to figure out what you changed after forking the project. If fact, you will see that you have been magically transported to Damien's repo that you had forked. If it all looks good you click "Create Pull Request" This lets you then create a comment explaining in more depth what you did and why you think the original author should merge your changes. Thereafter, once you have clicked "Create pullrequest" you will be done. Then it's in Damien's court to see if he wants to merge it or not.

FWIW, I can do this exact same thing if I wanted to - create a pull request of your code into his. Then it would show up as a pull request from me but a request to merge code from you. This is a perfectly valid thing to do but generally it's preferable if the actual author of the changes makes that call. My doing so would be pretty presumptuous though GitHub would allow it.

[EV_Builder]

COOL! thank u for explaining!

[johnspark]

I have just created an AVV50x ZombieVerter VCU connection page similar to the GS450H. I am just not sure where to put it, so I am dropping off here for now.

(If anyone finds mistakes or can think of improvements to this, very happy to change).


(I hope to interrogate the one I have very soon)

[streber]

Just a quick one - has anyone seen the OIL PUMP output working for the GS450 yet?
I get no PWM at pin 30 of the VCU or pin 40 of the STM32, when it's on and running. (Oil Pump is set to 50% in the menu)

Trying to narrow down if it's another bad STM chip problem or something else.

Thanks!

Did you figure this out?

I'm having the same issue. I think it is a software bug in hwinit.cpp: where it is using the wrong pin to setup the timer for the Oil PWM signal and putting it on the INV_POWER pin. I tried the obvious thing of fixing the pin in the code, but that didn't help.

[streber]

Just a quick one - has anyone seen the OIL PUMP output working for the GS450 yet?
I get no PWM at pin 30 of the VCU or pin 40 of the STM32, when it's on and running. (Oil Pump is set to 50% in the menu)

Trying to narrow down if it's another bad STM chip problem or something else.

Thanks!

Did you figure this out?

I'm having the same issue. I think it is a software bug in hwinit.cpp: where it is using the wrong pin to setup the timer for the Oil PWM signal and putting it on the INV_POWER pin. I tried the obvious thing of fixing the pin in the code, but that didn't help.

Figured it out. It also needed to remap the TIM1 pins. I'll send a pull request to get it fixed on the main branch.
https://github.com/damienmaguire/Stm32-vcu/pull/23

[EV_Builder]

please edit your pull request and add a SPI3 remap for the digipot.

[Kelju]

Until now I have been doing DC-link precharge manually on my test bench, but today I added some contactors and started testing.
I noticed one vulnerability in the code.
First of all, I thought that you only need to apply the start signal momentarily like in my daily (Th!nk City EV), but it turns out that you need to keep the start signal present as long as the precharge takes for Udc to rise to Udcsw. Otherwise the main contactor will not close.
Even after a successful precharge, there is room for error.
You remove KL15 (or T15) and the contactors open.
You also loose your Udc reading because you accidentally wired your ISA shunt to the switched Inverter power.
The Zombie will happily use the last Udc reading which is over the Udcsw while in reality, the DC-link voltage is gradually decaying.
Now you apply the start signal again and instantaneously BANG! the main contactors close because Udc>Udcsw...

Luckily I did not actually wire my main contactors straight between the battery and the Powertrain in the first place.

Mine was a wiring problem, but I guess the ISA shunt can also halt, which might lead to this situation.
Is there a way to include some kind of node guarding to the very important CAN messages?
I am thinking like a counter, that sets a parameter such as udc to zero if a new messages has not been received in let's say 50ms.
Also a fault would be set.

I think the same treatment would be needed for the current reading.

[johu]

Funny how the same problem occurs at the same time in two different places: https://openinverter.org/forum/viewtopi ... 328#p35328

I solved it pretty much like you suggest. I picked a random CAN message that is processed in the user callback and whenever it is received I set a counter to 10. Then in the 100ms task I decrement that counter. So if the message hasn't been received for 1s I know that. Since that message is only sent with ignition on I can use it as an indicator whether ignition is on or off.

When the counter reaches 0 I set udcinv to 0 to avoid above issue.

[Kelju]

In the mean time I also made my own implementation of the solution.
In the utils, I check a counter that it is below value 3 before updating Udc.
Whenever the CAN message for new value of Udc is received, I clear the counter back to zero.
If the counter rises too high, I set Udc to zero.
Seems to work as expected!

[Kelju]

Currently the precharge works in the way that DC-link voltage has to rise upto Udcsw and then the main contactor closes.
I think this is sub optimal because the delta voltage between battery and DC-link upon contactor closing will vary depending on SOC.
It would be more reasonable to measure the difference between battery voltage and DC-link and Udcsw would be the delta voltage.
The ISA shunt has the required additional HV-measurement channel for this.
Now, where can I locate the evaluation of STAT_UDCBELOWUDCSW?
This seems like the correct place to make the modification, right?

[Kelju]

Never mind, I think I found what I was looking for:

Code: Select all

    //////////////////////////////////////////////////
    //            MODE CONTROL SECTION              //
    //////////////////////////////////////////////////
    s32fp udc = utils::ProcessUdc(oldTime, GetInt(Param::speed));
    stt |= Param::GetInt(Param::potnom) <= 0 ? STAT_NONE : STAT_POTPRESSED;
    stt |= udc >= Param::Get(Param::udcsw) ? STAT_NONE : STAT_UDCBELOWUDCSW;
    stt |= udc < Param::Get(Param::udclim) ? STAT_NONE : STAT_UDCLIM;

[EV_Builder]

Figured it out. It also needed to remap the TIM1 pins. I'll send a pull request to get it fixed on the main branch.
https://github.com/damienmaguire/Stm32-vcu/pull/23

Damien and Streber;

Do you guys now if the other PWM outputs work at all?
Because if you use that remap command.

All other timer IO's will also be remapped away from the used one for PWM1,2 and 3.

Does somebody know if the N channels are usefull for normal PWM signals?

[Kelju]

I modified the code in a way that I now have deltaV showing the difference between battery and DC-link and I verified it to work via testing.
The problem is that I cannot seem to get the main contactor to obey.
In the "MODE CONTROL SECTION" as snipped into my previous message, if I write:

Code: Select all

    stt |= deltaV >= Param::Get(Param::udcsw) ? STAT_NONE : STAT_UDCBELOWUDCSW;  

Web interface says "waitforstart" as if DC-link was already precharged. I would expext it to say "UdcBelowUdcsw"

If I write:

Code: Select all

    stt |= deltaV >= Param::Get(Param::udcsw) ? STAT_NONE : STAT_UDCBELOWUDCSW;  

Web interface says "UdcBelowUdcsw"

In both cases, applying start results in instantaneous switching of main contactor along with the precharge.
Am I modifying the wrong section or just being a complete idiot in some other way?

[Jack Bauer]

Thanks for the contributions folks. Now merged on Github. Will look more closely soon. Up to my ears in woodworm this week!

[EV_Builder]

Thanks for the contributions folks. Now merged on Github. Will look more closely soon. Up to my ears in woodworm this week!

Yeah we try to contribute but its not easy missing information.

Would be awesome if you can answer my questions too...

I think they are easy: Should the PWM outputs work? are they tested?
Because i think they weren't and are connected to the wrong pins...

[Kelju]

I figured out another route to implement the precharge based on delta voltage.
In the Utils, I am tampering with the reading from the parameters.
I have my battery voltage in udc2.
At least based on initial testing, this seems to work.

Code: Select all

    s32fp udcsw = MAX(Param::Get(Param::udcsw), (udc2-10));
    Param::SetFlt(Param::udcsw, udcsw);

If we want the same functionality for the "general public", I suggest that someone who can actually code, would have a look into this.
The elegant way would obviously be that udcsw is the targeted voltage delta before closing the main contactor.

[johu]

Here is how I did it: https://github.com/jsphuebner/stm32-car ... r.cpp#L545
udcbms is the voltage reported by the BMS. Can of course be substituted by any other measurement before the HV relays. udcinv is the voltage reported by the inverter. Both are received via CAN. There is a sanity check that the BMS voltage must be at least 100V. Finally the parameter "bmsinvdiff" governs at what voltage difference the relay (may be) closed.
Like said udcinv resets to 0 when ignition turns off via a timeout mechanism.

[Jack Bauer]

I have not tested the pwm as yet. The pinout design was done using STM CubeMX to try and avoid assigning wrong pins / conflicts etc but its me so anything is possible. I have attached the CubeMX ioc file so it can be reviewed.

CubeMX is available here : https://www.st.com/en/development-tools ... t-software

[EV_Builder]

Thank u for explaining that. I re-checked and think i know it.
The pin assignment works a bit different then expected. For the other PWM pins we do need timer 14 and 15 from memory oh and more AFIO assignments...

Johu; Can you elaborate on your LIN driver? and can you tell me if N channel PWM outputs are useful for normal PWM modes?
Or should we look for assignment of CHx pins only?

[streber]

@EV_Builder I also haven't tested the PWM yet since those ICs were missing in my kit and I don't have a use for them yet.

@johu I found that the master branch is pulling a version of libopeninv that isn't remapping the CAN2 pins. I see remap support is in the newer versions of libopeninv. Do you have a preference on how to resolve this? I see a branch for updating libopeninv but not sure the state of it.