Two FOCCCI's on the same bus

[uhi22]

We have a confusion regarding the Clara version. On the github continuous integration page (on the "actions" tab) https://github.com/uhi22/ccs32clara/actions, there are the binaries available for each official version. The latest version is on the top of the list, with the highest run number. In this case, the #72 contains the fix:

In the "Artifacts" section of this run there are the zipped bin and hex files for flashing. After flashing, e.g. with STlink command line utility
ST-LINK_CLI -P stm32_canloader.hex -P CI_72.hex -V
the serial log of Clara should show the version:
This is Clara version 4=0.42.72.B
githubRunNumber 72
The 72 in the version and the githubRunNumber 72 are referring to the continuous integration build 72.

[hiro]

<Update 10/18/2024>

I updated the Clara firmware to version 4=0.42.73.B.
Then, I have had success using two chargers at the same time.

But it's not stable: sometimes it works, sometimes it doesn't.
I am attaching the log of when the double charge was successful.

Success Log Double charging.txt

(2.18 MiB) Downloaded 73 times

Also, after the firmware update I am losing communication using the ESP32 CAN Web Interface.


I would like you to look at this data and make improvements to ensure stable charging.

[jrbe]

<Update 10/18/2024>

I would like you to look at this data and make improvements to ensure stable charging.

If you're asking people to do things you should offer them a bounty / support them. If you are already, great.

[johu]

I would like you to look at this data and make improvements to ensure stable charging.

Please read the forum rules, especially #1 viewtopic.php?t=5714

If you are already, great

Not that I know of

[uhi22]

On first reading, I misread as
"I would like to look at this data and make improvements to ensure stable charging."
and thought "great, we have a new contributor".

The log of the good case does not help to understand the bad case. We need the log of the bad case for analysis.

[uhi22]

I am attaching the log of when the double charge was successful.

Summary of this log:
- It contains a failed part (see below) and a successful part afterwards.
- The intended bugfix, that we ignore foreign slac_match confirmations, works as intended:

Code: Select all

[294300] [PEVSLAC] received SLAC_MATCH.CNF but with foreign destination MAC. Ignoring.

- This is the first log from real world, where I saw that TCP retransmission is used and works:

Code: Select all

[297840] [TCP] Last packet wasn't ACKed for 100 ms, retransmitting

and succeeds after 10 retrys (TcpRetries 10). This is good, but it also indicates a quite bad physical connection.
- Later in the cable check, the TCP connection is lost completely after 10 retries, due to lost packages:

Code: Select all

[301260] [TCP] Last packet wasn't ACKed for 100 ms, retransmitting
[301370] [TCP] Giving up the retry

- The lost connection leads to the safe shutdown sequence, good.

Code: Select all

 [333920] Safe-shutdown-sequence: setting state B

- Afterwards, a normal charging session works.
- Session is stopped on charger side [599400] Checkpoint790: Charging is terminated from charger side.

[uhi22]

More interesting details: After the TCP gave up during CableCheck

Code: Select all

[300180] [TCP] Last packet wasn't ACKed for 100 ms, retransmitting
....
[301260] [TCP] Last packet wasn't ACKed for 100 ms, retransmitting
[301370] [TCP] Giving up the retry

the charger later sends again data

Code: Select all

[302160] ETH rx IP:

and the ping pong continues

Code: Select all

[302160] ETH rx IP:
[302160] [TCP] sending ACK

And after Foccci sent again a CableCheck request, we get from the charger

Code: Select all

[304190] ETH rx IP: 023304732057a0b0c0d2345b86dd6000000000140640fe80000000000000a2b0c0fffed2345bfe80000000000000c69083f3fbcb981ec350e754362bf283000001b45010038464f90000
[304280] ETH rx IP: 023304732057a0b0c0d2345b86dd6000000000140640fe80000000000000a2b0c0fffed2345bfe80000000000000c69083f3fbcb981ec350e754362bf283000001b45014038464f50000

and ignore these messages completely.

So two things to be done:
* The TCP timeout could be a bit longer than the currently implemented 10*100ms, because obviously sometimes the charger needs longer (~2s in this log).
* Analyze what messages does the charger send as last two, and why Foccci does not react on them.

[uhi22]

Clarified: The last two messages from the charger are just a TCP ack and reset:

This indicates that the charger does not want to further talk on this TCP connection (socket was closed).

So let's increase the TCP timeout and see how this improves the situation. Issue created: https://github.com/uhi22/ccs32clara/issues/43
[Edit] Done: https://github.com/uhi22/ccs32clara/com ... 21ef3d3ec4