Zombieverter and Tesla SDU Openinverter

[Steve16]

Johu, thank you for your patience and for repeatedly explaining the fixed mapping change here and in other topics. I believe I finally comprehend the can mapping described in the wiki and Zombie behavior: Zombie does not have the user selectable or automated capability (as of firmware 2.17) to provide canrun1/2 and cancrc for the fixed mapping implemented in OI firmware 5.32 and later.

As I am not yet a C++ coder, I will need help creating the code and compiling, or a release for Zombie in order to implement the enhanced can control safety features and other improvements starting with OI 5.32. I am happy to help with or test in any way for those working with Zombie code when they have time to get to it. Until then, I (and others) have a working solution with OI 5.27.

[tom91]

I'm not sure if Zombie uses this new method yet. I think Tom said it doesn't

It does, I checked. I will pull some info out of the raw code and add it to the wiki and here

Code looks to be straight from @Johu's STM32_Car. https://github.com/damienmaguire/Stm32- ... OI.cpp#L77

Receiving CAN is as follows:
0x190 Dec 400/Open Inv Msg. for RPM - speed 16 bits gain 1 start 0
0x19A Dec 410 /Open Inv Msg. for temps HS temp 16 bits gain 1 start 0
0x1A4 Dec 420/Open Inv Msg. for Voltage - udc 16 bits gain 10 start 0
0x1AE Dec 430/Open Inv Msg. for Opmode - opmode 8bits gain 1 start 0

image.png (7.49 KiB) Viewed 4036 times

[davefiddes]

The Zombieverter VCU firmware has had OI 5.32 CAN vehicle/throttle controller support since the V2.04 release.

Damien mentioned the feature in his V2.04 firmware release video:
He is using this in his "Panzer" with the Tesla LDU board.

I'm waiting for my VCU PCBs to arrive so can't test it myself right now. The code looks fine. It sends out the expected CAN frames with the fixed CAN ID of 0x3f. It should work correctly if you set the "controlcheck" paramter set to StmCrc8.

[Steve16]

I reviewed the section of the video again where Damien says can control is working, but he does not give any details. Since he is very good about giving details, I assume none are needed beyond selecting OpenI for the inverter. After clearing all mappings, I tried again and got an overcurrent error on the SDU. It turned out to be HVIL since I have never connected an HV cable to the unit. With HV cable and no HV power, I get a cancounter error on the SDU after power up and it will not go into run mode from Zombie start. It will go into run mode from the SDU start signal. I only see the error when can is connected between the units (nothing else is on the bus). Obviously, I still have an issue but have no idea how to proceed. It would seem that the Zombie is not providing the correct canrun checks, but I have no idea how I could have modified that function. Controlcheck in the SDU is set to StmCrc8.

[Bratitude]

I ran into cancounter errors when setting up my leaf oi board and zombie. Once I removed all the extra wiring from the oi board problems went away. I’m not sure if they are related. But perhaps do a bare bones wiring setup?

[Steve16]

I went back to bare bones wiring of power and CAN between Zombie and the SDU. I also used the Zombie start signal. After mapping the transmit values on the SDU as listed by Tom, Zombie receives data from the SDU, Zombie does not put the SDU in run mode using the Zombie start signal. After power-up, the SDU always reports cancounter error. Is there any way I can get more insight into the cancounter error from the SDU? I have assumed it found an error in the values in canrun1/2. However, if I have signal integrity issues, I would expect to get CRC errors also.

While trying different Zombie firmware (I confirmed the inverter parameter was correctly set for all versions), I noticed starting at version 2.05, Zombie does not read SDU data until in run mode (T15 and start active). I assume this was added to save energy in off mode. Is there a reason Zombie might want to read SDU data when T15 is active but in off mode? This may be too far off the initial subject to be appropriate to discuss here.

[johu]

Ignore CANRUN for now, it's a bit "trigger happy". It's just a warning. CANTIMEOUT is what you don't want.
Does status of SDU show WaitStart?

Does din_start go high on the SDU when you start on Zombie?

[Steve16]

Yes, the SDU shows WaitStart and will go into run mode when I apply the SDU discrete start signal, independent of Zombie state. I will check din_start.

[Steve16]

When I start on Zombie, din_start remains "OFF" in the web interface. I assume that is low.

[nubster]

FYI - Damien just dropped a couple of videos today discussing the new VCU v2.20A firmware. He also uploaded the parameter sets he's using with the VCU and LDU in the Panzer, which might provide some insight.



https://github.com/damienmaguire/Stm32- ... _220a.json
https://github.com/damienmaguire/Stm32- ... U_CAN.json

[Steve16]

I have tried upgrading to Zombie firmware 2.20 and then loaded Damien's parameters. In both cases, the SDU stays in waitstart when Zombie goes into run mode with Zombie start. I have compared Damien and my parameter files for Zombie and the SDU/LDU but have not recognized any differences that might be causing my problems. As a final test of Damien's settings, can I load his LDU parameters in my SDU if I'm only running 12V?

Trying to determine if Zombie is transmitting data on ID 0x3F, I connected Zombie and the SDU to a switched power supply and separately switched T15. I left Zombie at 2.20 and flashed the SDU back to 5.27, can mapped canio to 0x3F and the SDU goes into run mode with a Zombie start command. I then flashed the SDU up to 5.32 and tried again. The SDU does not go into run with Zombie start and it does not show any mapping for canio. Reverting back to SDU 5.27, the mapping reappears and the SDU goes into run mode with Zombie start. Between these tests, I left power on to Zombie and the SDU. I toggled T15 to get Zombie back into off mode. The SDU reverts back to off mode after flash. I also tried resetting can mapping then power cycling both units and my problem persists.

The SDU seems to ignore the 0x3F can mapping in 5.32 but clearly keeps it since it reappears when flashed back to 5.27. I assume I have changed something in the SDU which is causing my failure. Is it possible that I have a bit or bits in flash that I cannot see in the web interface that need to be reset or cleared? Is there a way to erase all parameter memory and/or firmware memory through the web interface? Perhaps with a command line? I'm assuming as long as the boot loader remains, I will be able to re-load firmware and default parameters.

[johu]

When I start on Zombie, din_start remains "OFF" in the web interface. I assume that is low.

Ok, then it must indeed be a counter or crc issue. Do you have equipment for a CAN log?

[tom91]

SDU back to 5.27, can mapped canio to 0x3F and the SDU goes into run mode

That is not good that there is a change from 5.27 to 5.32

[johu]

That is not good that there is a change from 5.27 to 5.32

I think it is quite logical. 5.27.R was the last version that allowed arbitrary mapping of canio, pot etc. So he flashes 5.27, manually maps 0x3F message as described in wiki, saves to flash and the inverter happily processes it as there are no further checks. He then flashes 5.32.R which unmaps the manual map of canio, but only in memory. It then doesn't work, apparently because either the counter or CRC check fails.

He reverts to 5.27 which loads the mapping from flash and works as before

[tom91]

I think it is quite logical

I disagree, as the code in Zombie was updated after the CAN change as I stated before.

EDIT 1: I reviewed the Zombie code, it is all there according to the wiki. However all the recieved values are hardcoded and the Zombie is not coded to be able to flash this profile to the OI inverter so this will need to be manual input.

The code in zombie is identical to the code from https://github.com/jsphuebner/stm32-car ... r.cpp#L471
It is ran every 10ms, no matter what mode the Zombie is in.

Damien also runs zombie with an Tesla LDU with OI firmware, or he has not been informed there was an update to the CAN functions and/or OI firmware?

EDIT:
https://github.com/damienmaguire/Stm32- ... -08-35.png

He is running 5.32

EDIT 2
How is the power wired to the SDU? I would advise using the Zombie Inverter Relay to provide 12V, confirmed with Damien this is how he runs it.

[johu]

I disagree, as the code in Zombie was updated after the CAN change as I stated before.

What I mean is you can configure the 5.27 software to process the same CAN message as later versions by mapping manually. It then behaves like 5.3x minus counter and CRC check.

The code in zombie is identical to the code from https://github.com/jsphuebner/stm32-car ... r.cpp#L471

Not exactly:

Code: Select all

 if(opmode==MOD_RUN) Param::SetInt(Param::canctr, (Param::GetInt(Param::canctr) + 1) & 0xF);//Update the OI can counter in RUN mode only

Since the 0x3f CAN messages is sent unconditionally in selectedInverter->SetTorque() instead of selectedInverter->Task10Ms() you are sending a stale counter and the inverter locks you out. Better to always increase the canctr, I don't see a drawback.

[tom91]

Better to always increase the canctr, I don't see a drawback.

Sure no idea who coded it, the whole implementation is abit rough and ready.

If you put the inverter/OI board on Zombie controlled power, as you should really for current consumption it works. This is the way Damien runs it.

[johu]

If you put the inverter/OI board on Zombie controlled power, as you should really for current consumption it works.

Ah yes, then that is probably the difference to Damiens setup?

Also in stm32-car Param::canctr is just for debug purposes. Might as well make it internal to the Can_OI class if it's not used by anything else. Makes it more self-contained.

[tom91]

Ah yes, then that is probably the difference to Damiens setup?

Also in stm32-car Param::canctr is just for debug purposes. Might as well make it internal to the Can_OI class if it's not used by anything else. Makes it more self-contained.

There is a few point to address on it, like how the start signal delay is passed on. Also that precharge can take some time thus can fault out an OI board.

Plus as you say general code tidying. Will raise an issue so I can look at it when I get going on the Zombie again.

[Steve16]

I have attached a log. Wasn't able to get my hardware working with savvycan but got it working with busmaster.

Power sequencing was mentioned earlier. My bench setup has both the SDU and Zombie power up at the same time (including T15) from a 12v car battery through a 5A fuse. I do not have a throttle connected, pot and pot 2 are typically 4 or 5.

[johu]

Yes, as expected the canctr is always 0

[tom91]

Power sequencing was mentioned earlier. My bench setup has both the SDU and Zombie power up at the same time (including T15) from a 12v car battery through a 5A fuse. I do not have a throttle connected, pot and pot 2 are typically 4 or 5.

Please use the Zombie- Inverter Power relay pin. This is a pull to ground pin to switch a relay that then provides power to SDU.

[Steve16]

Please use the Zombie- Inverter Power relay pin. This is a pull to ground pin to switch a relay that then provides power to SDU.

I will do the test when I get home this afternoon.

[Steve16]

I tested with SDU power supplied by a relay controlled with the inverter power relay pin. It seems to be part but not all of the solution. It does not put the SDU in run mode alone. When I tried to get a log, it does put the SDU in run mode. I believe I isolated the difference: when the logger is connected in the busmaster application at the time the Zombie start signal is applied, it works. All experiments have included the SDU power relay. I have tried to start leaving the Zombie on and toggling T15, bringing up Zombie and T15 power together, and bringing up Zombie then bringing up T15 manually. In all cases, the SDU only goes into run mode if hardware is connected in the busmaster application at the time of start. With busmaster disconnected, the SDU will not start. This is independent of the physical connection of my canbus adapter. It fails with the physical adapter attached but disconnected in the application. It also fails if the physical adapter is removed. I have noticed when logging during power up, there are commands written to ID 0x7DE. They may be a clue as to what is happening. I do not see ID 0x7DE in logs that I start after Zombie is powered up, yet the SDU still starts, so there may be other unseen things my adapter is doing on the bus. I have attached a log that includes the 0x7DE commands taken with power up of Zombie and T15 at the same time then Zombie start is applied. I have also attached my spreadsheet I used to sort the data, in case that is helpful.

[johu]

7DE is the boot loader. It sends it once at powerup