Zombieverter and Tesla SDU Openinverter

[Steve16]

In trying to get as close to Damien's implementation as I can, I added an ISA shunt to the bus (I don't have any of the other components). It is stubbed about 1/3 of the way between the Zombie and SDU and is unterminated. With power to the shunt, Zombie DOES start the SDU. To summarize the rest of my tests: for Zombie to start the SDU via Can, another powered device needs to be on the bus and the SDU needs to be powered by the Zombie inverter relay. Zombie parameter settings for the shunt appear to have no impact. In 2.20, it still works when ShuntType is None, ShuntCan is CAN2 (SDU & Inverter are CAN1) and IsaInit is Off.

Is it possible there is another dependency in the code that is met by the additional device? Something further than SDU power control to get the counters working? It seems we were expecting the inverter relay to fix the problem.

Someone else duplicating the issue with only Zombie and a Tesla drive unit on the bus would also be helpful.

[tom91]

Where are your termination resistors on the CAN bus?

[Steve16]

The SDU and Zombie are terminated.

[tom91]

What are the settings of your CAN logger when logging? Is it set to listen only?

It sounds like possible that Tesla SDU does not acknowledge any CAN frames.

[Steve16]

I was not able to easily find the settings. I also questioned if it was just listening. I will look again. The program I'm using is BusMaster.

[Steve16]

What are the settings of your CAN logger when logging? Is it set to listen only?

It sounds like possible that Tesla SDU does not acknowledge any CAN frames.

I found the settings. My logger was set in normal mode. When I changed to listen only, the Zombie does not start the SDU. It does start in all other modes including "Normal (no-ACK)." My testing was done with just the SDU, Zombie, and Zombie start relay. The listen only log is attached.

Does this suggest the SDU might not acknowledge CAN frames?

[tom91]

Does this suggest the SDU might not acknowledge CAN frames?

That is very possible bus also very weird, hopefully Johu can shed some light on this.

[johu]

There is a suspicious amount of boot loader "hello" frames 0x7de. Should just be one. And likewise the 0x3f frames come in at a way too low interval. I assume the CAN-able bootloader is flashed to the VCU as well?
While the SDU is powered down of course it can't ACK. When powered up it will. Zombie and inverter use the same CAN lib.

[Steve16]

I assume the CAN-able bootloader is flashed to the VCU as well?

Is there a way I can verify the version of the bootloader? I'm using the version that came with the Zombie board.

I looked into boot at powerup more closely. The Zombie will send the "hello" frames on 0x7DE until it gets a response or times out. Using my logger in "normal noACK" mode, the hello is sent once before a response is sent. When the ISA shunt is on the bus (same power supply as Zombie, logger in "listen only" mode), the hello is repeated until a response is sent. I assume this takes longer as the shunt needs to boot to be able to respond. The logs with response are: SDU_start_logger_noACK and Start_with_shunt_logger_listen_only. I did not bother to attach a log showing the timeout.

I also tested with just the logger and had it in "normal noACK" mode while the Zombie powered up, then switched the logger to "listen only" before applying Zombie start. In this case, the SDU does not go into run mode. I believe there is stimulus needed at powerup of both the Zombie and the SDU in order to get the Zombie to start the SDU. The log for this is: Listen_at_SDU_powerup.

Do we believe the counter issue mentioned earlier is the answer to the problem?

I'm wondering if we are at a practical end to this issue. Do we need to look into this further, or am I beating a dead horse? Since we know that the issue goes away if the inverter relay is used and there is another device on the bus, is this enough? Is it likely in real implementations that no other devices will be on the bus?

I will be happy to gather more data as requested or test any firmware updates.