Session stopped after Charge Parameter Discovery Response

[nikunjp26]

Platform: EVSE Firmware Version: i.e. V02_00_01 Host Controller Interface: Ethernet Host: Own Implementation

We have integrated Whitebeet module running EVSE firmware version V02.00.01 with our CCS2 charger with single gun only. we connect only single Whitebeet module on the Ethernet. We are getting the session stop error just after the "Charge Parameter Discovery Response" command. during the charging of Mahindra xuv400 ev car. same charger is working fine with other cars.

Please support us quickly to solve this issue as we are not able to charge this car.

Please find the attached logs which capture using the Greenshark XUV400_13042023.zip

let us know if need more details.

[lho-stx]

Hey @nikunjp26,

the EV sends a SessionStopReq, which is not allowed after a ChargeParameterDiscovery. Therefore the Whitebeet stops with a SessionError. The EV does not comply to the sequence defined in the standard. If the EV wants to signal an error it shall close the TCP connection.

I see no reason why the EV can not handle the response, all parameters are in range and the timeout requirements are also met (time for the EVSE sending the answer is ~1s).

The EVSE Status Code in DC EVSE Status is set to "EVSE not ready (0)". Please try setting it to "EVSE ready (1)" prior to ChargeParameterDiscoveryRes and see if the EV then proceeds.

Can you do me a favor and send me a wireshark log of a successful charging session with another EV (and tell me which EV was used)?

Thank you, lho

[nikunjp26]

Dear Iho,

Please find the below logs files with successful charging sessions.

1) Hyundai Kona EV hyundai_kona_76_to_100_40Amp_Success.zip

2) Tata Nexon EV Nexon_wireshark_13122022.zip

[nikunjp26]

Dear Iho, We tried as per your suggestion, and you can find the below logs of different scenarios which we tested here with the xuv400 ev car but still we are not success to charge the car and still car is stopping the session.

We also observed the below strange behavior during our different trials. it will be good if you explain more about this.

1. Communication was stop in service discovery process if we select the ISO15118 Protocol.
2. Communication was stop after the charge parameter discovery if we selected the DIN protocol.

xuv_charge_ISO15118_and_isolation_Invalid.zip xuv_charge_parameter_request_failed_single_transaction.zip xuv_ISO15118_Selected.zip

Waiting for your quick support as we are stuck at this point.

let us know if need more details.

Best Regards, Nikunj Patel

[lho-stx]

Hey @nikunjp26,

I am sorry to hear this. I will investigate the logs and share my findings with you.

Best regards, lho

[nikunjp26]

Dear Iho,

here i am attaching the logs which captured on uart which can help you . We got some warning with below messages during testing.

[ 683.792] [WARN ] V2GDIN12: V2GSVC_NC_SENT notification in wrong state (V2GMH_DIN12_STATE_RECV_EXI).

[ 2626.800] [WARN ] APL-ETH: # Unhandled Ethernet notifycode 365

[ 2733.038] [WARN ] SLAC: Unexpected message!

[ 2733.068] [WARN ] SLAC: Unexpected message!

teraterm.log

[lho-stx]

Hey @nikunjp26,

The V2GDIN12 warning occurs for example when a message was not parsed completly and a new message arrives. To tell you more about this I would need more inforamtion of the situation. The ethernet message just indicates that the ethernet module has no implementation for this notify code. These messages are ok, it indicates the EVSE not in state for receiving specific SLAC messages, but it catches up after the messages.

I inspected the logs mutliple times and I just do not see any problem in the protocol messages. Do you have any sort of debug information from the vector unit? Maybe there is a hint from vector side.

Thank you, lho

[nikunjp26]

Dear Iho,

We don't have any debug information for the Vector unit as this is the logs of XUV400 EV car.

Thanks

[lho-stx]

Hey,

we are currently working on different issues and will come back to you as soon as possible!

Thank you for your patience, lho

[nststx]

Hi @nikunjp26,

I've taken a look at your issue and don't see a problem on communication level. All exchanged parameters are normal and timeout requirements met. Maybe there's an issue on the lower level. Do you already apply any voltage on the DC connectors at that time? You could also try modifying the parameters slightly. For example regarding schedules, e.g. shortening the schedule duration, adding a second schedule etc. Maybe there's something in there that the car is not happy with. Do you have any sort of information about why the charging session is failing on the cars dashboard?

Best regards, Niklas Stoffers

[nikunjp26]

Dear Niklas,

This issue is specific to xuv400 car. Right now we don't have this car. when we got it will it charge again and will check the dashboard with that and tell you.

best regards, nikunj patel

[nststx]

Hi @nikunjp26,

Thanks for your response. Take your time and let me know once you've been able to charge the car again.

Best regards, Niklas Stoffers

[nikunjp26]

Dear Niklas,

you can refer the today's logs as per #173 ticket (but there was no any single success case)

Best Regards, Nikunj Patel

[nststx]

Hi @nikunjp26,

Thanks for your response. I will need some more time to look into this and let you know once I've got an update.

Best regards and thanks for your patience, Niklas Stoffers

[nikunjp26]

Dear Iho,

Here we attached logs of two different sessions of Nexon Car of success and failure scenario. can you please help to find out that what is the wrong happening in the failure sceraio? based on that we can improve our code.

wb_naxtion_max_fail.zip wb_nextion_max_success.zip

Best regards, Nikunj Patel

[nikunjp26]

Dear Iho, can you please check the log on priority and update us what is the difference/wrong in the failure scenario so we can modify our code as per that?

best regards, nikunj patel

[lho-stx]

Hey @nikunjp26,

in the log that is failing the host sends the same messages twice (e.g. 725+726, the whitebeet answer is in 727). The first one is missing the padding bytes, the second one is padded. The Whitebeet only sends the answer once.

In the session not failing the messages are only send once (although the padding is missing.)

I don't know if this is the reason why the session fails, but try to fix the duplicate messages and see if this resolves your issue!

Best regards, lho

[nikunjp26]

Dear Iho, We will confirm again with the CAR and reply back.

Best Regards, Nikunj Patel

[nikunjp26]

Dear Iho, After a waiting of too many days, today, we checked with Nexon MAX Car and it is working on first try and charged to 100% without any issue. We will check further whenever CAR is available for more confidence. However, at first instance, it is working.

Best Regards, Nikunj Patel

[yuanbo20]

Excuse me, which controller do you use? White Beet ？

[nikunjp26]

Dear Iho,

Closing this issue as right now able to charge with Nexon Car.