ESP32 CAN Web Interface <-> Zombieverter [SOLVED]

[Scrappyjoe]

Hello,

Starting a new thread because my earlier questions were around the Olimex interface, which I have given up on.

I am posting to find out if there are any software configurations required to get the ESP32 web interface board communicating with the Zombieverter.

After my Zombieverter Olimex stopped broadcasting a WiFi SSID, I decided to get an ESP32 CAN Web Interface from the Openinverter store. It arrived this week and I soldered on the headers and connected GNB, 12V, CANH and CANL and powered up the Zombie and the ESP32 board.

I can join the SSID and navigate to the interface, but I am getting the dreaded "Communication problem between ESP and STM" banner on the top.

The Zombieverter power led is on and the activity led is flashing rapidly. Incidentally, the Olimex red led is on but the SSID is nowhere to be found.

When I turn on my ignition and press start, my precharge procedure initiates and completes. This suggests to me that the CAN network that the Zombieverter, ESP32 board and IVT-S shunt are on is working. I am assuming the ESP32 board does not have a terminating resistor enabled by default - the Zombie and IVT shunt have a resistor.

https://openinverter.org/shop/index.php ... duct_id=78

So, my question - is there anything I need to do, software-wise, to get the ESP32 showing me Zombieverter spot values and parameters?

I see a Node ID field - clicking up and down on that does nothing.
I assume 500kb speed is fine.
Do I need to do anything in the CAN mappings section?
Anything else I have not done?

I'm sort of pulling out my hair now. I made good progress on setting up precharge and the throttle pedal, but then I lost access to my interfaces so I am stalled.

[johu]

The ESP32 module uses SDO communication. On ZombieVerter that is only available on CAN1. Node Id is 3
I'm assuming you've got recent firmware on Zombie. Like 2.20

[Scrappyjoe]

Hi johu! Good info, thank you kindly.

[Scrappyjoe]

Well, I'm not having any joy. It's probably user error on my part, which I'm sure is exasperating for the old hands on here because once you know, it's obvious

When you say CAN1, do you mean A or B in the picture below? I know I have seen posts on here that mention that the references change sometimes.

Further assumptions that I am making:

1. Both of these CAN interfaces have a terminating resistor in the Zombieverter
2. The ESP32 does not have a terminating resistor.

I think I am on 2.17, but I lost the Olimex webui when toggling between 2.05, 2.15, 2.17 and 2.20 trying to get a stable connection. Are there any other Node IDs that were used?

If I fail at this I think the next step will be to pop out the Olimex and reflash it manually. Either that or spend some $ to 'phone a friend'

[Scrappyjoe]

So I got out my multimeter to test out assumption (1) above. Turns out that:

1. I get 120 ohm across my IVT shunt CAN lines - it has a resistor in it according to the specs, so this is expected.
2. I get 0 ohm across the Zombie CAN EXT (A above) lines
3. I get 0 ohm across Zombie CAN EXT2 (B above)
4. I get 120 ohm across my USB Can Dongle, which has a resistor built in.
5. When I make a 2 node CAN network including the IVT shunt and one of the Zombie can connections (either one), the resistance on that network is 120 ohm.
6. When I make a 2 node network including the IVT shunt network on one end and my terminated dongle on the other end, the resistance is 60 ohm.

This leads me to conclude that the Zombieverter CAN connections to not have a built in resistor, which really surprises me since I have been happily reading voltages off my IVT shunt for precharging!

The conclusion I am forced to reach is that somehow the CAN network worked fine with just one terminating resistor for the special case of just 2 nodes. As soon as I add another node to the network it all breaks.

This explains so much - I have been really struggling to get anything else communicating on these CAN lines, and now I know why. I will reconfigure CAN 1 (which I assume is A above unless corrected) to be properly terminated and then see if I have any luck.

Oh, also, for the record - ESP32 is also not terminated as shipped (just checked with multimeter). But I think you can solder a short enable termination.

[Scrappyjoe]

Ok, I appear to be getting somewhere. I shortened all my CAN network stubs to less than 30cm. I spaced all my stubs along the main CAN line. Terminated on both ends.

Now, when I select NodeID 3 in the interface:

1. The red banner on the top disappears
2. In Chrome Developer Tools > Network I am getting HTTP code 200 responses from cmd?cmd=json.

So it looks like we are getting comms! Unfortunately, no spot values are showing. If I go to http://192.168.4.1/cmd?cmd=json I get a single value back :

"43014149"

Spot values are all undefined, if I try download the parameters I just get an empty json file. If I try upload a new stm32_vcu.bin, I get 1% in and then the interface locks up, I cannot navigate away or visit 192.168.4.1 from another tab - it's just frozen, and I need to reboot.

[Scrappyjoe]

It locks up immediately after the call http://192.168.4.1/fwupdate?step=1&file ... _vcu-2.bin

The one immediately before, http://192.168.4.1/fwupdate?step=0&file ... _vcu-2.bin, gives me a 200. But the one that locks up does not give me a response.

[Scrappyjoe]

Turns out I was wrong on the successful comms with the Zombie. I was looking in the files section to see if I should delete some old stm32_vcu.bin files, and I found a json file called 2c389.json. The contents were suspiciously familiar:


"43014149","isparam":false}
}
"serial": {"unit":"","value":"43014149"


That's it - broken json. When I deleted the file from the ESP32, the dreaded red banner came back.

http://192.168.4.1/cmd?cmd=json now gives (as before):

CAN communication error

[johu]

Looks like an outdated libopeninv . You really need a very fresh Zombie build.

[Scrappyjoe]

I'm in awe that you can figure that out from my feedback. Make sense though. Ok, I will go buy an ST-Link v2, download the 2.20a hex file and load it. Thanks johu.

[Scrappyjoe]

Alright, mission accomplished!

Flashed the Zombie with an ST-Link V2, flashed the Olimex with a UART cable, all working now.

Thanks again for your guidance johu. The most surprising thing about all of this for me was that the Zombie can fail in a 'soft' way, resulting in a somewhat functional board.

The wired flashing was very intimidating, but I guess there is no substitute for a complete reflash at a certain point.

I've left a bit of guidance here on any workarounds I had to figure out while flashing the Olimex via UART -

viewtopic.php?p=80706#p80706

[Scrappyjoe]

Although I no longer need to get the ESP32 communicating with the ZombieVerter because my Olimex is back up and running, I feel honour bound to try answer the original question because I couldn't find an answer when I was looking, and others will probably land on this forum post when they want to connect the ESP32 to the ZombieVerter.

So. I have:

1. A ZombieVerter on firmware v 2.20A.
2. An Olimex on the latest commit
3. Precharge is working with CAN1 as the selected Shunt CAN interface.
4. The STM32 is connected on the same CAN line as the IVT Shunt.
5. Node 3 is selected, speed is 500k

On the Olimex/ESP8266 I get full comms with the Zombie. On the ESP32 I get no comms.

Is there anything I have missed?

Thoughts:

1. Perhaps my CAN network topology is messed up - although the Zombie reads shunt values fine.
2. Perhaps CAN1 in the interface is not CAN1 as described by johu above?
3. Perhaps I need to somehow enable SDO comms by setting a parameter on the Zombieverter?
4. Perhaps there is something I need to set up in the ESP over and above setting Node ID 3 and speed 500k?

Attached my existing parameter file (most stuff I left default, just the udc params have been set)

[Scrappyjoe]

I have managed to successfully connect the ESP32 to the ZombieVerter. In the end, I changed nothing from my last post. For clarity, here is the configuration that works for ZombieVerter V2.20. A lot of this is documented in many places, but I'm repeating it here anyway.

1. Connect the ESP32 to CAN1 of the ZombieVerter - that is the CAN lines closest to the 12v/GND pins on the ZombieVerter pinout.
2. Make sure you have the right resistor termination. That is, when powered down, the resistance between CANH and CANL must be approximately 60 ohm. If it's 120 ohm, you only have one terminating resistor, if it is under 60, then you have too many.
3. Power to the Zombie and the ESP32 are the same 12v lines.
4. The WIFI network will be something like ESP_xxxx, no password
5. The web interface is 192.168.4.1
6. The only things I needed to set were Node ID 3. Speed is 500k, which is the default. I select these values by pressing the up button a few times in the box and then hitting 'Enter' for good measure.


How did I connect?

Well, firstly, try different browsers. I had no luck with Safari - and even the inbuilt Zombie web interface is flaky on Safari. Chrome worked better. I did not test Firefox.

Secondly, I think perhaps there's a bit of a startup issue. I powered up and joined the wifi network and went to the web interface in Chrome, and initially had not connection. I waited a bit, toggled the auto reload a few times, refreshed a couple of times and voila! It worked. SO I think patience is sometimes a virtue.

Here is a screenshot of the CAN parameters that I have right now, in case you are wondering.

[johu]

Was just going to reply to your questions Will anyway

Perhaps my CAN network topology is messed up - although the Zombie reads shunt values fine

Probably no

Perhaps CAN1 in the interface is not CAN1 as described by johu above?

Maybe.. just try the other

Perhaps I need to somehow enable SDO comms by setting a parameter on the Zombieverter?

No

Perhaps there is something I need to set up in the ESP over and above setting Node ID 3 and speed 500k?

No

[Jacobsmess]

I have found clearing cookies can help when swapping between different WebUI devices

[johu]

Yeah definitely Ctrl+F5
It doesn't use cookies so it's the cache I'd think