Add plc chip reset to ev_slac

[SebaLukas]

Describe your changes

The reset function from the Evse ported to the Ev.

Issue ticket number and link

The Ev Slac module lacks the function to reset the PLC chip after each session

Checklist before requesting a review

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• I read the contribution documentation and made sure that my changes meet its requirements

[SebaLukas]

The test with real HW is missing

[corneliusclaussen]

check out this draft PR:

#809

It is not ready for merging yet because of a hardcoded 10s delay after reset, but it changes the sections in EvseSlac that you copied over to EvSlac in this PR. Maybe you can change it to be more similar to #809, then it will work with both QCA and Lumissil.

[SebaLukas]

Thx for the suggestion. I will have a look 👍

[SebaLukas]

I took a closer look at #809. As I understand it, I'm adding a 10s delay after the Lumissil reset. Until we have found a better method for the Lumissil.
The new NMK state does not need the EV, as the network is only joined in the matched state.

[lategoodbye]

Hi, could you please give a short motivation of this change?

There are several methods to trigger a reset of the PLC. The chose one here has the best independence from hardware & kernel, but it's also the most unreliable way to do because it needs a working firmware. Another downside is the involved complexity.

[SebaLukas]

Hi :)

As the QCA sometimes has problems joining the network, it always needs a soft reset after each charging session. This is solved using this method. As far as I know, we cannot reset the QCA via the HW pin on Linux.

On the Evse side, the reset is implemented in the same way and has worked very well since it was added. That's why I simply ported it to the EV side.

What would the other methods look like?

[lategoodbye]

Hi,
i understand. The QCA700x has Reset-GPIOs which could be pulled from userspace (Linux Mainline QCA7000 driver doesn't support reset handling itself), but sure it's possible there are bad hardware designs which doesn't connect the reset line.

The qcaspi driver support a reset via SPI commands, which is more low level than a reset via MME. This solution doesn't work in case the QCA7000 is connected via UART, but i never saw in a real Embedded Linux product with this. Unfortunately there is currently no way to trigger this reset from userspace, but Linux ethtool generally provides such a userspace API. Recently i started to work on this feature. Here is a draft based on top of Linux 6.10.

The big advantage of the ethtool API it is generic interface. AFAIK the Vertexcom MSE102x doesn't provide SPI commands to trigger a reset, so there is a low chance to adapt it for this driver.

[corneliusclaussen]

I think we should add reset via GPIO as well (in a separate PR) as an option for boards that have this pin connected to the Linux board (also for the EVSE side)

[SebaLukas]

This is on hold because the feature getting the info which chips is installed is missing