search

Sevenstax / FreeV2G

Python based Host MPU Application for the use with 8DEVICES WHITE-BEET Embedded ISO15118 Module modules to realize IEC/ISO15118 and DIN70121 conform charging communication between electric vehicles (PEV) and elevtric vehicle supply equipment (EVSE). FreeV2G can e.g. been used with a Raspberry Pi.
Other
57 stars 26 forks source link

Question: SPI communication failure due to re-sync #296

Closed FivaTagin closed 5 months ago

FivaTagin commented 7 months ago

Hi There,

Currently we are using STM32G4 as our controller to communicate with Whitebeat

The system generally operates as intended; however, we frequently encounter synchronization issues where the TX_PENDING ping cannot be reset by the WB site.

Upon examining the data packet with a logic analyzer, it appears that the host site (STM32) has received the full length of the payload. Nonetheless, the WB site fails to reset the TX, preventing the host site from proceeding with subsequent processes.

The digital signal log, recorded by DSView, is attached for reference. To pinpoint the issue I've highlighted, please refer to the last data package in the log. Double header.zip

lho-stx commented 7 months ago

Hey @FivaTagin,

thank you for creating log files, but unfortunately we do not offer support for DSView. Please create the log files with Saleae Logic2 or KingstVIS if possible, or create a .csv dump of the SPI traffic with the following header:

Time [s],Packet ID,MOSI,MISO

Where MOSI and MISO are the hex values of the bytes seen on the SPI lines.

Your understanding is valued, lho

FivaTagin commented 7 months ago

Hi @lho-stx Thanks for your reply,

The attachment is the csv file if it helps. You may find the problematic timestamp from this file. Feel free to advise any questions if you may have. image

virtual-session-la-240403-141159.csv

Best Regards,

Josh.

lho-stx commented 7 months ago

Hey @FivaTagin,

unfortunately you logfile does not comply to the requested format. I need the packet ID in order to see which bytes belong to which packet. Is it possible to add this information to the logfile?

Best regards, lho

FivaTagin commented 7 months ago

Hi @lho-stx ,

Sorry to hear the file does not work.

We have just upgraded our communication driver with Whitebeet, we will get back to you if this issue still occur under this update.

Much appreciated

Josh.

github-actions[bot] commented 6 months ago

This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.

FivaTagin commented 6 months ago

Hi @lho-stx We have tried to enhance our communication with whitebeet, it still works most of the moments. But we found there is a situation that is confusing to be handled. As the following picture shows in the middle of our command sent via MOSI. The TxPending event was triggered by Whitebeet.

What does the host system need to handle this situation? Because as you can see although we could receive the ack message from MISO. But the TX pending has never gone off.

I would appreciate it if you could help us review the following pictures because you are not using the same digital analyser. These are the screenshot if it helps.

image

image

image

FivaTagin commented 6 months ago

and we also found a non-response issue on whitebeet during the charging.

For example, in Image 1, the timing shows when WB is finishing the charge process. At this time, the host was delivering the end charge event mod: 0x27 cmd: 0x63, but a TX pending event also came in at the same moment. Following up in Image 2, the WB should deliver the confirmation event by 0x27 0x63 instead of delivering a full data package with all 0xAA. Then, the WB triggered another TX pending event, but this time there was no further valid header or subsequent data package.

I wonder if you can advise the concern about this behaviour, I am wondering if it a wrong operating timing to catch the TX pending event.

image 1. DSView-240430-142706

image 2 DSView-240430-152535

lho-stx commented 6 months ago

Hey @FivaTagin,

I want to focus on the first set of pictures for now. Just for my understanding:

  1. you send a size exchange frame, during this frame the tx pending line went high
  2. you are sending your data exchange frame. It is hard for me to understand the next flow, because somehow github removed this image, I can only see the preview. But for me it seems you are sending your data.
  3. Then you try to read back the pending TX frame shown in the last picture.

For me this looks ok. Did you try to read back more TX frames? Because

When the SPI_TX_PENDING pin is high there is at least one full framing message ready to be reveived by the host.

(taken from Whitebeet manual p. 40).

Now to the last set of pictures:

With the first size exchange frame the Whitebeet tells you that it has 44 pending bytes (0x2c), but you only send out 28 bytes of data (0x1c). Therefore there is more data in the Whitebeet TX buffer. You need to transfer the maximum of the two values, so the Whitebeet can send out its data completely. Just pad your data with 0x00 if the Whitebeet has more data to send then the host.

Please try the suggestions and let me know if this resolves your issues!

Best regards, lho

github-actions[bot] commented 6 months ago

This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.

github-actions[bot] commented 5 months ago

This issue was closed because it has been inactive for 7 days since being marked as stale. If your issue still persists, feel free to reopen!