1-Communication problem between esp and stm (intermittent, now 99% of time) and 2-Cannot map CAN signals

[reesha]

Hello,

Hello,

I have an OpenInverter board running firmware sine-5.35, connected to an ESP32 WiFi module.

**Problem 1)**

I've had an intermittent communication problem from the beginning. Sometimes it worked, but often the web interface shows the message: "communication problem between ESP and STM".

For the last 4 days, I haven't been able to make it work at all. The ESP32 always stops communication after receiving this specific response from the inverter:
Chn Identifier Flg DLC D0...1...2...3...4...5...6..D7 Time Dir
0 00000601 8 40 00 31 00 00 00 00 00 64.286480 R
0 00000581 8 80 00 31 00 00 00 02 06 64.286730 R - invertor negative answer
0 00000601 8 40 80 31 00 00 00 00 00 64.287160 R
0 00000581 8 80 80 31 00 00 00 02 06 64.287400 R - invertor negative answer
Logging stopped.

This is one of the shortest full logs. I also have many longer ones – all end the same way.

I reflashed the inverter firmware, tried many resets, load default params, reconnected things, used Python tools, etc.
After two days of attempts, it suddenly worked **once** (yesterday). I also logged that session.

Here's the relevant portion of that working session, where the same request/response occurs but the communication **continued**:
0 00000581 8 43 07 21 F0 00 00 00 00 128.777420 R
0 00000601 8 40 08 21 06 00 00 00 00 128.777680 R
0 00000581 8 43 08 21 06 60 05 05 00 128.777950 R
0 00000601 8 40 07 21 F3 00 00 00 00 128.778220 R
0 00000581 8 43 07 21 F3 43 00 00 00 128.778480 R
0 00000601 8 40 00 31 00 00 00 00 00 128.922890 R
0 00000581 8 80 00 31 00 00 00 02 06 128.923140 R - invertor negative answer
0 00000601 8 40 80 31 00 00 00 00 00 128.923580 R
0 00000581 8 80 80 31 00 00 00 02 06 128.923830 R - invertor negative answer
0 00000601 8 40 00 21 01 00 00 00 00 130.700660 R
0 00000581 8 43 00 21 01 40 E7 00 00 130.700900 R
0 00000601 8 40 00 21 02 00 00 00 00 130.701240 R
0 00000581 8 43 00 21 02 40 20 00 00 130.701490 R
0 00000601 8 40 00 21 86 00 00 00 00 130.701750 R
0 00000581 8 43 00 21 86 00 32 00 00 130.702000 R
0 00000601 8 40 00 21 63 00 00 00 00 130.702260 R
0 00000581 8 43 00 21 63 40 38 00 00 130.702500 R


So my question:
**Why does ESP32 abort communication after the first 0x0031 SDO Abort in most cases, but sometimes continues?**

Could this be a bug or overly strict error handling in ESP32 firmware?

---

**Problem 2)**

While debugging, I used `openinverter_can_tool` to send `can clear`, `can save`, and attempted to create new CAN mappings.

I did this twice, and after the last `can clear`, I am no longer able to create *any* CAN mappings. Even during the one time the web interface worked, the mappings could not be created.

This seems like a separate issue – possibly corrupted CAN mapping table or EEPROM?

Here's one of the logs showing this:
Chn Identifier Flg DLC D0...1...2...3...4...5...6..D7 Time Dir
0 000007DE 8 33 31 00 00 25 52 07 43 991.103094 R
0 00000601 8 40 00 50 03 00 00 00 00 996.749354 R
0 00000581 8 43 00 50 03 85 78 01 00 996.749594 R
0 00000601 8 23 00 31 02 00 00 00 00 997.805974 R
0 00000581 8 80 00 31 02 00 00 02 06 997.806224 R
0 00000601 8 23 80 31 02 00 00 00 00 997.808094 R
0 00000581 8 80 80 31 02 00 00 02 06 997.808344 R
0 00000601 8 23 00 30 00 35 01 00 00 997.816224 R
0 00000581 8 60 00 30 00 35 01 00 00 997.816474 R
0 00000601 8 23 00 30 01 D2 07 00 10 997.817944 R
0 00000581 8 60 00 30 01 D2 07 00 10 997.818204 R
0 00000601 8 23 00 30 02 E8 03 00 00 997.819244 R
0 00000581 8 80 00 30 02 00 00 02 06 997.819514 R
Logging stopped.


Any help would be highly appreciated.

Thanks!

[johu]

The protocol to receive CAN mappings is designed this way. You query the next mapping until you receive an abort.

Now I went through the logs and found there was a fix specifically about deleting CAN mappings. This could lock up in certain cases and inhibit further communication.
You can check if that is the case by pulling up the web UI until you get the "failed" message. Then power cycle inverter and ESP module but LEAVE the UI open! Then do NOT hit the browser refresh button but simply turn on Auto refresh. You should now see the parameters.

You can then flash the binary that I attached which has the bug fixed.

One more thing: you shouldn't be able to load defaults. If you did anyway this would inhibit further operation with the SDU. So you'd have to restore the parameters from your backups.

Also reflashing the same firmware over and over never solves a problem. But I understand why people do it, it seems the only way out...

[reesha]

Hello Johu,

thank you for your response.

I tried uploading your firmware. The WEBUI reported that it had been uploaded, but the upload completed in just one second, so I suspect it was not successful.
I then restarted the inverter, but nothing changed. After that, I uploaded the official sine 5.35 release again (which took a few seconds), and now the CAN mappings work!

The communication error between the ESP and STM still occurs, but not always. When it happens, I power-cycle the ESP Wi-Fi module (OFF/ON), and communication resumes without errors.

So I would like to say—my problems are mostly solved, or at least I now have a workaround. Your answer helped a lot—thank you!

I still have a couple of questions:

1) Should I try uploading the firmware you sent again? Is it a public version?

2) I’m having trouble getting the motor to run again. I suspect this is due to my previous successful attempt to load defaults on the inverter. I believe I have reconfigured everything as before, but the motor still doesn't behave as expected.
I suspect hidden parameters might be involved (for example, encmode, which I don’t see in the interface).
I've been trying to read or access hidden parameters since yesterday but haven’t found a way.

3) I do not know what exactly happens during Load default function. But from what I see a suppose these parameters are probably different from params which have been loaded when this board came to me..? Are you able to provide the parameters which have been preloaded in Tesla LDU board before shipping?

Could you please advise how I can read or modify these hidden parameters?

[reesha]

An update..
I have finally found a way how to read and write the hidden parameters.
Solution: using openinverter can tool and sine.5.24R parameter database.

The car is finally running, thank you.

Interesting note:

Also reflashing the same firmware over and over never solves a problem. But I understand why people do it, it seems the only way out...

It is curious, but it really helped - as I wrote in my last post. Of course, only one time - not repeating this procedure again and again.

The questions:
1) Is there any other way how to change hidden parameters (for example over webUI)?
2) Shall I flash inverter board with the file which you (Johu) has sent as an attachment to this thread? What for version is it? Is it a public release? I am asking because I haven't seen anything newer than 5.35R on github.

Thank you