Getting started with framing over SPI and custom host controller

[pradhanbiswajit]

Your Setup Platform: PEV / EVSE White-beet module - WB-CARRIER-BOARD-EI 1.1 Firmware Version: i.e., V01_00_07 Host Controller Interface: SPI Host: Own Implementation - NXP Controller

Describe the bug We are facing the following issues with white beet module (EVSE ISO15118, WB-CARRIER-BOARD-E1.1) communication with the control card (MIMXRT1024 EVK): -

1. Once the SPI_RXReady pin gives high, the controller starts the spi communication asap. The first response read from white beet module is always some random value. When wait for the next SPI_RXReady interrupt to read the data again from the module, the ready pin doesn't go low to high again. So, I could only get one response.

2. If read the data from white beet module irrespective of the status of the SPI_RXReady pin after the first rising edge has appeared then the SPI_RXReady pin goes from low to high then high to low irregularly throughout and sometimes getting random data on spi, sometimes getting proper response with some extra bytes showing in the beginning of the frame, not according to the sevenstex document.

3. It is getting out of sync time and again.

Below is the request and response format we are using - Firmware version message - CS-Low -> 20us delay -> send size exchange frame (0xAA | 0xAA | 0x00 | 0x0C) -> CS-High -> CS-Low -> 20us delay -> send data exchange frame (0x55 | 0x55 | 0x00 | 0x00 | 0xC0 | 0x10 | 0x41 | 0x06 | 0x00 | 0x00 | 0x00 | 0xC1) -> CS-High -> CS-Low -> 20us delay -> read Response (30 bytes) -> CS-High

Also want to understand if I am doing something wrong in using the SPI_TXPending and SPI_RXReady pin. Tried to go according to the sevenstex documentation but very limited is given. If could get some more insight on the functionality of these pins, then will be really helpful.

To Reproduce Checked the SPI_RXReady pin and SPI_TXPending pin signal in oscilloscope again and again.

Expected behavior As per the sevenstex documentation, once the SPI_RXReady pin goes from low to high, the spi transfer should start between the host controller and the white beet. As the pin goes high, I send the size-exchange-frame first then the data exchange frame. After sending data exchange frame I read the data from the white-beet module. It should give the proper data with the start of frame and the end of frame and the module id, subid, request id, no. of bytes as per the documentation. Synchronization should be maintained between the host and white beet and shouldn't give garbage data.

Logs ![WhatsApp Image 2023-02-08 at 16 52 28](htt

https://user-images.githubusercontent.com/48279117/218243758-26071ab0-f67c-4ef7-a4f0-b395948d1776.mp4

ps://user-images.githubusercontent.com/48279117/218243726-96bb2339-72f4-418b-b082-b5be420cef8e.jpeg) https://user-images.githubusercontent.com/48279117/218243749-618d18e4-7a95-4bab-9713-e221a068f75a.mp4

Additional context

https://user-images.githubusercontent.com/48279117/218243767-7709e6fd-67da-493d-8866-f6145c70b1ac.mp4

Add any other context about the problem here.

[lho-stx]

Hey @pradhanbiswajit,

first of all thank you for your detailed issue description!

Indeed I think there is some confusion about the functionality of the RxReady- and TxPending-Pin.

RxReady goes high as soon as the Whitebeet is ready for SPI communication. It only shows that the module is in a state to receive SPI communication, it does not signal that a transmission for the host is available (in short: the host can communicate with the Whitebeet).

TxPending goes high as soon as there is valid data in the buffer of the Whitebeet. Then the host can read valid data from the Whitebeet (in short: the host should communicate with the Whitebeet).

Therefore, if you want to read data from the Whitebeet you need to wait for TxPending going high. If you just want to send data to the Whitebeet you can start transmission when RxReady goes high.

Please let me know if this information is sufficient to resolve your issue!

Thank you, lho

[pradhanbiswajit]

Hey,

I am doing the same thing. Sending the size exchange frame and the data exchange frame when the RxReady pin goes low to high. After sending the data exchange frame i wait for the TXPending pin to go high then read the data from the whitebeet module. But still getting garbage data.

Below are the oscilloscope images of MISO, MOSI, SCK, CS, SPI_RXReady and SPI_TXPending signals for reference.

1. The first five images are when I am not reading anything, just sending the size exchange frame and data exchange frame.

2. The next six images are when reading the response from whitebeet module when SPI_TXPending pin goes low to high after sending the size and data exchange frame after SPI_RXReady pin goes high.

Kindly, Go through the images and let me know the issue and the possible solution.

Regards Biswajit

On Tue, Feb 14, 2023, 14:21 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

first of all thank you for your detailed issue description!

Indeed I think there is some confusion about the functionality of the RxReady- and TxPending-Pin.

RxReady goes high as soon as the Whitebeet is ready for SPI communication. It only shows that the module is in a state to receive SPI communication, it does not signal that a transmission for the host is available (in short: the host can communicate with the Whitebeet).

TxPending goes high as soon as there is valid data in the buffer of the Whitebeet. Then the host can read valid data from the Whitebeet (in short: the host should communicate with the Whitebeet).

Therefore, if you want to read data from the Whitebeet you need to wait for TxPending going high. If you just want to send data to the Whitebeet you can start transmission when RxReady goes high.

Please let me know if this information is sufficient to resolve your issue!

Thank you, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1429347227, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TLVBLUCCBSUHNYLJCDWXNBRBANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[pradhanbiswajit]

Hye, Iho

Thanks for your prompt response.

In the sevenstex usermanual, there seems contradiction. At one page it is written that when the SPI_RXReady pin goes high then need to send size and data exchange frame but in the example oscilloscope image given in the usermanual the RXReady pin is low when the exchange frames are being send to the whitebeet module. Also the data is read from the module when the SPI_TXPending pin in low which contradicts with the previous statement on SPI_RXReady pin functionality in the usermanual.

Below are the reference from the usermanual. The size and data exchange frames are given in the third image.

Please clarify on this also.

Regards Biswajit

On Tue, Feb 14, 2023 at 6:12 PM Biswajit Pradhan < @.***> wrote:

Hey,

I am doing the same thing. Sending the size exchange frame and the data exchange frame when the RxReady pin goes low to high. After sending the data exchange frame i wait for the TXPending pin to go high then read the data from the whitebeet module. But still getting garbage data.

Below are the oscilloscope images of MISO, MOSI, SCK, CS, SPI_RXReady and SPI_TXPending signals for reference.

1. The first five images are when I am not reading anything, just sending the size exchange frame and data exchange frame.

2. The next six images are when reading the response from whitebeet module when SPI_TXPending pin goes low to high after sending the size and data exchange frame after SPI_RXReady pin goes high.

Kindly, Go through the images and let me know the issue and the possible solution.

Regards Biswajit

On Tue, Feb 14, 2023, 14:21 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

first of all thank you for your detailed issue description!

Indeed I think there is some confusion about the functionality of the RxReady- and TxPending-Pin.

RxReady goes high as soon as the Whitebeet is ready for SPI communication. It only shows that the module is in a state to receive SPI communication, it does not signal that a transmission for the host is available (in short: the host can communicate with the Whitebeet).

TxPending goes high as soon as there is valid data in the buffer of the Whitebeet. Then the host can read valid data from the Whitebeet (in short: the host should communicate with the Whitebeet).

Therefore, if you want to read data from the Whitebeet you need to wait for TxPending going high. If you just want to send data to the Whitebeet you can start transmission when RxReady goes high.

Please let me know if this information is sufficient to resolve your issue!

Thank you, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1429347227, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TLVBLUCCBSUHNYLJCDWXNBRBANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

you are right, the SPI_RXReady pin is low during transmission, but this is due this ongoing transmission. This is also true for the TxPending pin. The order of the pin levels are:

Rx-/TxPending goes high > chip select goes low (Whitebeet is selected) > Rx-/TxPending goes low (due to the chip select being low) > transmission of frames > chip select goes high > Rx-/TxPending goes high when Whitebeet

Tomorrow I can create another log of the SPI communication and send it to you, maybe this will clearify things.

Unfortunetaly there a no images in your two latest post, maybe you need to reupload the images again?

Best regards, lho

[pradhanbiswajit]

1. Green(SPI_RXReady) - Yellow(SPI_TXPending)
2. Green(SPI_RXReady) - Yellow(MOSI)
3. Green(SCK) - Yellow(MOSI)
4. Green(CS) - Yellow(MOSI)
5. Green(MISO) - Yellow(MOSI)
6. Green(MISO) - Yellow(MOSI) - 2
7. Response from whitebeet module
8. Green(MISO) - Yellow(SPI_TXPending)
9. Green(MISO) - Yellow(SPI_RXReady)
10. Garbage data with occasional proper data
11. Hexadecimal byte representation of ASCII data
12. Screenshot 2023-02-14 183016
13. Screenshot 2023-02-14 183053
14. Screenshot 2023-02-14 183206

[pradhanbiswajit]

Hey, Iho

The RXReady pin goes low to high then high to low between the ongoing data transfer from master to slave as can be seen from the second image. Should it behave like this ?

[pradhanbiswajit]

I have uploaded the images again. The RXReady pin goes from low to high then high to low in between the data transfer.

On Tue, Feb 14, 2023 at 8:20 PM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

you are right, the SPI_RXReady pin is low during transmission, but this is due this ongoing transmission. This is also true for the TxPending pin. The order of the pin levels are:

Rx-/TxPending goes high > chip select goes low (Whitebeet is selected) > Rx-/TxPending goes low (due to the chip select being low) > transmission of frames > chip select goes high > Rx-/TxPending goes high when Whitebeet

Tomorrow I can create another log of the SPI communication and send it to you, maybe this will clearify things.

Unfortunetaly there a no images in your two latest post, maybe you need to reupload the images again?

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1429869030, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TP6SRK7M7JNCHDAZFDWXOLUJANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

first of all thank you for your effort!

I have created a capture of the SPI communication between Whitebeet and FreeV2G on a RaspberryPi host to give you a reference how the signals shall behave.

Regarding your pictures: It is really hard to identify problems by just looking at a two channel oscilloscope image when debugging SPI communication. Do you have the possibillity to use an actual multichannel logic analyzer? This would help alot! If not you can try to watch at RxReady and CS at the same time, then you can compare your signals to the ones in the images below.

Nevertheless, the RxReady pin should stay low as long as the CS pin is asserted and the transmission of size exchanges frames has not finished yet.

In this picture the handling of the RxReady is shown (here it is a host initiated transmission).

After reset, the RxReady pin goes high, the host selects the Whitebeet by asserting the CS line. At this point a transmission is "ongoing", even when there is no clock. You can see that the RxReady pin is asserted until the size exchange frame is send successfully. Then the RxReady pin goes high again, because the module is ready for communication. This differs between a size exchange frame and a data frame, because after a size exchange frame the host needs to know when to send the data frame. I've talked to a colleague and he agreed this behavior is inconsistent, because the RxReady pin should immediately go low again, when the CS pin is still asserted.

In the next picture the size exchange frame is shown in detail.

It is shown, that the host wants to send 8 bytes of payload to the Whitebeet module.

In this picture you see the process of sending a data frame from the host to the Whitebeet module.

Like before, the RxReady pin is high, CS is asserted, RxReady goes low.

Now please have a look at the next picture, which are showing the handling of the TxPending pin (so a Whitebeet initiated transmission). First a size exchange frame is send (TxPending & RxReady high > CS low > RxReady low > size exchange frame > RxReady high > CS high), then the data frame is send (TxPending & RxReady high > CS low > RxReady low > data frame > TxPending low > CS high).

You can see as soon as the data was send the TxPending pin is going low. Here the RxReady pin keeps low, because the Whitebeet needs time to catch up. In the next picture you can see the RxReady pin goes high after some time.

I hope this helps to clarify things!

Best regards, lho

[pradhanbiswajit]

Hi, Iho

Thanks for making so much effort to help me.

I have a small doubt. Do we need to assert the CS again to read the response from the whitebeet module after sending the data exchange frame or we need to read in the same CS in which we send the data exchange frame? In the image shared above, I think you have red the response from the whitebeet in the same CS in which you have send the data exchange frame. Can you please clearify on this?

Thanks Biswajit

On Wed, Feb 15, 2023 at 6:53 PM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

first of all thank you for your effort!

I have created a capture of the SPI communication between Whitebeet and FreeV2G on a RaspberryPi host to give you a reference how the signals shall behave.

Regarding your pictures: It is really hard to identify problems by just looking at a two channel oscilloscope image when debugging SPI communication. Do you have the possibillity to use an actual multichannel logic analyzer? This would help alot! If not you can try to watch at RxReady and CS at the same time, then you can compare your signals to the ones in the images below.

Nevertheless, the RxReady pin should stay low as long as the CS pin is asserted and the transmission of size exchanges frames has not finished yet.

In this picture the handling of the RxReady is shown (here it is a host initiated transmission).

[image: FreeV2G_150_SPI_RxReady] https://user-images.githubusercontent.com/103272216/219025417-742f01c0-c753-42fe-9539-0051a16188c0.png

After reset, the RxReady pin goes high, the host selects the Whitebeet by asserting the CS line. At this point a transmission is "ongoing", even when there is no clock. You can see that the RxReady pin is asserted until the size exchange frame is send successfully. Then the RxReady pin goes high again, because the module is ready for communication. This differs between a size exchange frame and a data frame, because after a size exchange frame the host needs to know when to send the data frame. I've talked to a colleague and he agreed this behavior is inconsistent, because the RxReady pin should immediately go low again, when the CS pin is still asserted.

In the next picture the size exchange frame is shown in detail.

[image: FreeV2G_150_size_exchange_frame_tx] https://user-images.githubusercontent.com/103272216/219028035-1693b459-1884-4660-bf36-d6ceb83d2ac7.png

It is shown, that the host wants to send 8 bytes of payload to the Whitebeet module.

In this picture you see the process of sending a data frame from the host to the Whitebeet module.

[image: FreeV2G_150_data_frame_tx] https://user-images.githubusercontent.com/103272216/219029728-b1b54b43-fcbe-44ba-8fd4-f85b20c03dc2.png

Like before, the RxReady pin is high, CS is asserted, RxReady goes low.

Now please have a look at the next picture, which are showing the handling of the TxPending pin (so a Whitebeet initiated transmission). First a size exchange frame is send (TxPending & RxReady high > CS low > RxReady low > size exchange frame > RxReady high > CS high), then the data frame is send (TxPending & RxReady high > CS low > RxReady low > data frame > TxPending low > CS high).

[image: FreeV2G_150_SPI_TxPending] https://user-images.githubusercontent.com/103272216/219036639-6f0e7c1d-dd0c-4008-bfd8-901acdce3a09.png

You can see as soon as the data was send the TxPending pin is going low. Here the RxReady pin keeps low, because the Whitebeet needs time to catch up. In the next picture you can see the RxReady pin goes high after some time.

[image: FreeV2G_150_SPI_TxPending_2] https://user-images.githubusercontent.com/103272216/219036666-eb88412a-c8df-4db3-9405-b03cb2225822.png

I hope this helps to clarify things!

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1431364166, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TPUQSYEX3E5ZR5GPETWXTKFDANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

yes, you need to de-assert and assert the CS line between size exchange frame and data frame. Please see the last image, after the size exchange frame is send, CS (Channel 3) is de-asserted and asserted again before sending the data frame.

Best regards, lho

[pradhanbiswajit]

Do we need to dessert CS between data exchange frame and whitebeet response?

Regards Biswajit

On Fri, Feb 17, 2023, 15:24 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

yes, you need to de-assert and assert the CS line between size exchange frame and data frame. Please see the last image, after the size exchange frame is send, CS (Channel 3) is de-asserted and asserted again before sending the data frame.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1434400262, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TIAETVDRO33LWBYBKDWX5DGTANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Yes, you need to de-assert after every SPI transmission.

Best regards, lho

[pradhanbiswajit]

In the images above, I cannot see de-assert CS after sending data exchange on MOSI and before receiving data from whitebeet on MISO.

[pradhanbiswajit]

One more thing I want to ask, I think 23 bytes are received on MISO as per the image and 12 bytes should be send on MOSI in data exchange frame as per usermanual. In the usermanual for the same example of firmware version the no. of bytes sending in response is 17 bytes.

I am unable to understand this difference. Kindly, clarify.

Regards Biswajit

[lho-stx]

Hey @pradhanbiswajit,

regarding the CS de-asserting, I misunderstood your question, I apologize.

Because SPI is full-duplex, the data on MOSI and MISO are send at the same time. The SPI transmission consists of a identifier followed by the framing data. This is a single SPI transmission, therefore you must not de-assert the CS line.

Connection between size exchange frame and data frame

In the following picture the size exchange frame is shown.

Here the identifier (0xAA 0xAA) is send, followed by the size of the framing payload (0x00 0x08) is send on MOSI. The slave will expect 8 bytes of data on the MOSI line in the next data frame.

Note: This is different from framing data payload size!

Note: Because SPI is full-duplex the slave will also send the identifier (0xAA 0xAA) and size of data (0x00 0x00) it will send in the next data frame. Here the MISO data size is 0.

In the next picture the corresponding data frame is shown.

The master sends the identifier (0x55 0x55 0x00 0x00) followed by the 8 framing data payload bytes. Please refer to Whitebeet Manual chapter 10 for more details on the structure of the framing data. Here the framing data consists of:

0xC0 0x10 0x41 0x01 0x00 0x00 0x2B 0xC1

This can be translated to

Start symbol: 0xC0 Mod Id: 0x10 Sub Id: 0x41 Request Id: 0x01 Size: 0x00 0x00 (none) checksum: 0x2B Stop symbol: 0xC1

On the MISO line there is the identifier, followed by 8 zero bytes, because the slave does not want to transmit valid data to the host (see the first picture).

Obtain the firmware version

In order to get the firmware version you need two sets of size exchange and data frames.

First you need to send the example given above:

Send a size exchange from the host to the slave:

0xAA 0xAA 0x00 0x08

Then you need to send the data exchange frame with the framing data:

0x55 0x55 0x00 0x00 0xC0 0x10 0x41 0x01 0x00 0x00 0x2B 0xC1

Then you will need to wait for the TxPending pin to go high and send a new size exchange frame. This time the slave will send the size of the data on the MISO line it wants to send to the host in the next data frame.

Now de-assert the CS line, assert the CS line again, send the data frame identifier (0xAA 0xAA 0x00 0x00), check if the slaved also send the data frame identifier. If yes read the number of bytes received in the latest size exchange frame.

Here you can see how the 23 bytes seen on the MISO line are coming from.

Note: The size of the array holding the firmware version varies. In the manual the size of the firmware version is 7, in the show example it is 9.

I attached the capture of the example here:

whitebeet_spi_example_traffic.zip

You can look at it by using the free version of Saleae Logic

I hope this helps with your understanding and implementation.

Best regards, lho

[pradhanbiswajit]

Hey, Iho,

Thanks, for the waveforms. Will check on my side.

Regards Biswajit

On Mon, Feb 20, 2023 at 7:39 PM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

regarding the CS de-asserting, I misunderstood your question, I apologize.

Because SPI is full-duplex, the data on MOSI and MISO are send at the same time. The SPI transmission consists of a identifier followed by the framing data. This is a single SPI transmission, therefore you must not de-assert the CS line. Connection between size exchange frame and data frame

In the following picture the size exchange frame is shown.

[image: FreeV2G_150_size_exchange_frame_tx] https://user-images.githubusercontent.com/103272216/220121208-adf256b0-c52b-482a-a508-95500b51a2f7.png

Here the identifier (0xAA 0xAA) is send, followed by the size of the framing payload (0x00 0x08) is send on MOSI. The slave will expect 8 bytes of data on the MOSI line in the next data frame.

Note: This is different from framing data payload size!

Note: Because SPI is full-duplex the slave will also send the identifier (0xAA 0xAA) and size of data (0x00 0x00) it will send in the next data frame. Here the MISO data size is 0.

In the next picture the corresponding data frame is shown.

[image: FreeV2G_150_data_frame_tx] https://user-images.githubusercontent.com/103272216/220121280-8360ee9d-2bb5-4c07-bafd-795cf4aa0284.png

The master sends the identifier (0x55 0x55 0x00 0x00) followed by the 8 framing data payload bytes. Please refer to Whitebeet Manual chapter 10 https://raw.githubusercontent.com/Sevenstax/FreeV2G/EVSE_v2.0.1_4/SEVENSTAX_WhiteBeet_UserManual.pdf#page=45 for more details on the structure of the framing data. Here the framing data consists of:

0xC0 0x10 0x41 0x01 0x00 0x00 0x2B 0xC1

This can be translated to

Start symbol: 0xC0 Mod Id: 0x10 Sub Id: 0x41 Request Id: 0x01 Size: 0x00 0x00 (none) checksum: 0x2B Stop symbol: 0xC1

On the MISO line there is the identifier, followed by 8 zero bytes, because the slave does not want to transmit valid data to the host (see the first picture). Obtain the firmware version

In order to get the firmware version you need two sets of size exchange and data frames.

First you need to send the example given above:

Send a size exchange from the host to the slave:

0xAA 0xAA 0x00 0x08

Then you need to send the data exchange frame with the framing data:

0x55 0x55 0x00 0x00 0xC0 0x10 0x41 0x01 0x00 0x00 0x2B 0xC1

Then you will need to wait for the TxPending pin to go high and send a new size exchange frame. This time the slave will send the size of the data on the MISO line it wants to send to the host in the next data frame.

[image: FreeV2G_150_size_exchange_frame_rx_fw_version] https://user-images.githubusercontent.com/103272216/220127578-bc65ffda-6eb5-49fd-b67f-31809d2d95f6.png

Now de-assert the CS line, assert the CS line again, send the data frame identifier (0xAA 0xAA 0x00 0x00), check if the slaved also send the data frame identifier. If yes read the number of bytes received in the latest size exchange frame.

[image: FreeV2G_150_data_frame_rx_fw_version] https://user-images.githubusercontent.com/103272216/220127647-11f7b34c-51e1-41be-a61b-e2084ee80c78.png

Here you can see how the 23 bytes seen on the MISO line are coming from.

Note: The size of the array holding the firmware version varies. In the manual the size of the firmware version is 7, in the show example it is 9.

I attached the capture of the example here:

whitebeet_spi_example_traffic.zip https://github.com/Sevenstax/FreeV2G/files/10785107/whitebeet_spi_example_traffic.zip

You can look at it by using the free version of Saleae Logic https://www.saleae.com/downloads/

I hope this helps with your understanding and implementation.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1437081690, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TOP5OZEGWUN6N733A3WYN3K3ANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

I am closing this ticket. If you need more time or support to resolve your issues please re-open!

Best regards, lho

[pradhanbiswajit]

Hi, Iho

Thanks for your support.

There is a small issue that I am still facing. The synchronisation breaks in between many a times. the RXReady waveform also changes on the oscilloscope.

Please check the below images. What can be done to resolve this issue.

[pradhanbiswajit]

the yellow one is the RXReady and green one is Chip Select

[lho-stx]

Hey @pradhanbiswajit,

your waveforms look quiet good in my opinion. The RxReady goes low, as soon as CS goes low, I see no problem there.

I do not get the ASCII print you've send. You are using Docklight, right? Isn't it for RS232/UART only?

We can try to sort out the problem, but it would be much much more comfortable if you had access to a multichannel logic analyzer where you can see the waveforms. If your company does not have any, there are cheap ones by az-delivery for 10 bucks each. They are sufficient for the most low level bus debugging tasks and compatible with Saleae Logic Software.

If it is not possible that you get access to a logic analyzer, I need a capture of all SPI signals that are aligned properly in time. Maybe you can use a pin of your custom board as external trigger to your scope. Then create multiple measurements, for each signal (Clock, MOSI, MISO, CS, RxReady, TxPending).

The problem here is to find a setting in which it is possible to read the actual transmitted bytes.

Best regards, lho

[pradhanbiswajit]

Dear Iho,

No problem, Have already ordered a multichannel logic analyzer. But will take time to receive. Will try to send proper waveforms with the external trigger.

Thanks, Biswajit Pradhan

On Mon, Feb 27, 2023, 19:22 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

your waveforms look quiet good in my opinion. The RxReady goes low, as soon as CS goes low, I see no problem there.

I do not get the ASCII print you've send. You are using Docklight, right? Isn't it for RS232/UART only?

We can try to sort out the problem, but it would be much much more comfortable if you had access to a multichannel logic analyzer where you can see the waveforms. If your company does not have any, there are cheap ones by az-delivery https://www.az-delivery.de/en/products/saleae-logic-analyzer?variant=27889816585 for 10 bucks each. They are sufficient for the most low level bus debugging tasks and compatible with Saleae Logic Software.

If it is not possible that you get access to a logic analyzer, I need a capture of all SPI signals that are aligned properly in time. Maybe you can use a pin of your custom board as external trigger to your scope. Then create multiple measurements, for each signal (Clock, MOSI, MISO, CS, RxReady, TxPending).

The problem here is to find a setting in which it is possible to read the actual transmitted bytes.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1446359119, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TODPVMD7VP6YK57T7TWZSWSBANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

this is good to hear.

Looking forward to your log files!

Best regards, lho

[lho-stx]

Hey @pradhanbiswajit,

do you have any news? If the issue is not present anymore I would like to close this ticket.

Best regards, lho

[pradhanbiswajit]

Right now I am not working on this project. Soon will get back to this project. Shifted to anathor project on priority.

Regards Biswajit

On Fri, Mar 17, 2023, 13:39 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

do you have any news? If the issue is not present anymore I would like to close this ticket.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1473348484, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TJCA4PLPO24FG25V23W4QL2PANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[pradhanbiswajit]

Hi,

The communication is stable now but I am facing anathor issue. Not able to write data through SPI. I am trying to write serial number but am getting 0xFF in response. I looked in sevenstex manual, it is written Internal error. What can be the issue and can I resolve it.

Regards Biswajit Pradhan

On Fri, Mar 17, 2023, 15:21 Biswajit Pradhan @.***> wrote:

Right now I am not working on this project. Soon will get back to this project. Shifted to anathor project on priority.

Regards Biswajit

On Fri, Mar 17, 2023, 13:39 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

do you have any news? If the issue is not present anymore I would like to close this ticket.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1473348484, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TJCA4PLPO24FG25V23W4QL2PANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[pradhanbiswajit]

Hi,

Whenever I am trying to read any data from whitebeet module and send parameters in payload in the request to the whitebeet module then I am getting internal error(0×FF). What can be the issue?

Regards biswajit Pradhan

On Sun, Apr 9, 2023, 07:35 Biswajit Pradhan @.***> wrote:

Hi,

The communication is stable now but I am facing anathor issue. Not able to write data through SPI. I am trying to write serial number but am getting 0xFF in response. I looked in sevenstex manual, it is written Internal error. What can be the issue and can I resolve it.

Regards Biswajit Pradhan

On Fri, Mar 17, 2023, 15:21 Biswajit Pradhan @.***> wrote:

Right now I am not working on this project. Soon will get back to this project. Shifted to anathor project on priority.

Regards Biswajit

On Fri, Mar 17, 2023, 13:39 lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

do you have any news? If the issue is not present anymore I would like to close this ticket.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1473348484, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TJCA4PLPO24FG25V23W4QL2PANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

there are multiple reasons why this error occurs. Can you please provide log files of the Whitebeet UART in .txt form and a recording of the SPI traffic (either as decoded bytes as .csv file or a recording combatible to Saleae Logic/Kingst)?

Thank you, lho

[pradhanbiswajit]

Hi,

Sorry for delay in replying as was busy somewhere elso. I will try to provide the whitebeet UART logs. About the SPI traffic, I have to check once if there is log provision in the oscilloscope. There is another issue I am facing, I have tested the Framing module, System module, Control Pilot module, SLAC module and PLC module. The Framing, system and control modules are working fine but the SLAC and PLC module are not responding properly. Communication break is happening when I am testing the SLAC and PLC messages. The same isnt happening with the former three modules. Do I need to test the SLAC and PLC modules with the vehicle or vehicle side simulator or I can test without any vehicle or simulator?

Regards Biswajit Pradhan

On Wed, Apr 12, 2023 at 5:43 PM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

there are multiple reasons why this error occurs. Can you please provide log files of the Whitebeet UART in .txt form and a recording of the SPI traffic (either as decoded bytes as .csv file or a recording combatible to Saleae Logic/Kingst)?

Thank you, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1505169097, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TOKAW6TQEGSKBLBQMDXA2MAFANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

yes you would need to attach an actual EV/EV simulation in order to fully test this modules. The SLAC module initiates the SLAC process and times out, if there is no SLAC response. Do you have access to other QCA700x based PLC hardware? If yes you might use open-plc-utils for SLAC testing.

What do you mean by Communication break is happening ? Because you should be able to communicate with the modules at all without EV attached.

Best regards, lho

[pradhanbiswajit]

Hi,

Can you provide me with document with whitebeet evse side PLC flow diagram that it follows when communicates with EV to implement the charging process.

Regards Biswajit Pradhan

On Mon, Jun 5, 2023 at 12:32 PM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

yes you would need to attach an actual EV/EV simulation in order to fully test this modules. The SLAC module initiates the SLAC process and times out, if there is no SLAC response. Do you have access to other QCA700x based PLC hardware? If yes you might use open-plc-utils https://github.com/qca/open-plc-utils for SLAC testing.

What do you mean by Communication break is happening ? Because you should be able to communicate with the modules at all without EV attached.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1576159692, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TPZUBFDAUNN4SXGTULXJWABFANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

please have a closer look into the Whitebeet manual chapter 19 Application Examples. You can find flow charts and message examples for succesfull SLAC and V2G communication in there.

I will close this issue for now, because I think the initial problems are solved. If you have specific questions do not hesitate to open a new issue.

Best regards, lho

[pradhanbiswajit]

Hi,

I also think that the initial issues are resolved but still some things which i am exploring and finding certain issues in it. There are status messages in the CP service. I am trying to handle those messages but facing synchronisation issue as the status messages are asynchronous and can be send at any time as per the manual. Can you suggest me an effective way to handle the status messages in CP service. It would be really helpful if you can send me any logic analyzer waveforms like before comprising of the regular as well as status messages which shows handling of status messages without any synchronisation issue. It should give some insight to handling this issue.

Regards Biswajit Pradhan

On Thu, Jun 8, 2023 at 3:31 PM lho-stx @.***> wrote:

Closed #150 https://github.com/Sevenstax/FreeV2G/issues/150 as completed.

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#event-9470346976, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TPKAFZTRF3OAUKQDQLXKGPJHANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

I may create a log with Saleae Logic2 of a complete charging session. The software is free of charge and you can have a closer look in the log by yourself when you install it. I can place markers on specific events in the log file, so you don't need to search the messages by yourself. Would this be sufficient for you?

Best regards, lho

[pradhanbiswajit]

hi,

Yeah, this should help a lot. Thanks!

Regards Biswajit Pradhan

On Fri, Jun 9, 2023 at 11:33 AM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

I may create a log with Saleae Logic2 of a complete charging session. The software is free of charge and you can have a closer look in the log by yourself when you install it. I can place markers on specific events in the log file, so you don't need to search the messages by yourself. Would this be sufficient for you?

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1584021337, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TNYXNFBWO4RSW7T3SLXKK4D3ANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[pradhanbiswajit]

hi,

Any update?

Regards Biswajit Pradhan

On Fri, Jun 9, 2023 at 11:50 AM Biswajit Pradhan < @.***> wrote:

hi,

Yeah, this should help a lot. Thanks!

Regards Biswajit Pradhan

On Fri, Jun 9, 2023 at 11:33 AM lho-stx @.***> wrote:

Hey @pradhanbiswajit https://github.com/pradhanbiswajit,

I may create a log with Saleae Logic2 of a complete charging session. The software is free of charge and you can have a closer look in the log by yourself when you install it. I can place markers on specific events in the log file, so you don't need to search the messages by yourself. Would this be sufficient for you?

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1584021337, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TNYXNFBWO4RSW7T3SLXKK4D3ANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hello @pradhanbiswajit,

I apologize for the delay. Here is the SPI log of the full charging session:

full_charging_session.sal.txt

I needed to add .txt to the file, or else github does not allow me to upload the file. The channels should be already annotated.

Best regards, lho

[pradhanbiswajit]

Hi,

I am going through the waveforms to understand the process but it would be really helpful if I can get the process or flowchart of the charging session in textual format. In the meantime I would try to understand it.

Regards Biswajit Pradhan

On Tue, Jun 13, 2023 at 9:27 PM lho-stx @.***> wrote:

Hello @pradhanbiswajit https://github.com/pradhanbiswajit,

I apologize for the delay. Here is the SPI log of the full charging session:

full_charging_session.sal.txt https://github.com/Sevenstax/FreeV2G/files/11736837/full_charging_session.sal.txt

I needed to add .txt to the file, or else github does not allow me to upload the file. The channels should be already annotated.

Best regards, lho

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#issuecomment-1589595496, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TOA2XLB2O3XXZAHAXLXLCEWBANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[lho-stx]

Hey @pradhanbiswajit,

if the examples in the Whitebeet manual is not sufficient for you, I think you need to get access to the ISO15118 and DIN70121, I can not provide you these documents. You may also have a look to charin, an organization working for unified charging standards.

Closing for now, because the issues are solved. If you have specific questions regarding Whitebeet specific questions please open a new issue.

Thank you, lho

[pradhanbiswajit]

Hi,

I was going through the waveform .sal file that you had sent me recently. It is not matching with the document messages for CP service, SLAC or any other service. Means I am seeing messages starting with 0x50 and 0xb4. It isnt matching with the document messages. I think you might have sent me some other logs. Can you once check on your side?

Regards Biswajit Pradhan

On Wed, Jun 14, 2023 at 4:01 PM lho-stx @.***> wrote:

Closed #150 https://github.com/Sevenstax/FreeV2G/issues/150 as completed.

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#event-9526685830, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TLBSDMU3L2YT3EQUALXLGHH3ANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>

[pradhanbiswajit]

Hi,

Any update on this?

Regards Biswajit Pradhan

On Tue, Jun 20, 2023, 11:10 Biswajit Pradhan @.***> wrote:

Hi,

I was going through the waveform .sal file that you had sent me recently. It is not matching with the document messages for CP service, SLAC or any other service. Means I am seeing messages starting with 0x50 and 0xb4. It isnt matching with the document messages. I think you might have sent me some other logs. Can you once check on your side?

Regards Biswajit Pradhan

On Wed, Jun 14, 2023 at 4:01 PM lho-stx @.***> wrote:

Closed #150 https://github.com/Sevenstax/FreeV2G/issues/150 as completed.

— Reply to this email directly, view it on GitHub https://github.com/Sevenstax/FreeV2G/issues/150#event-9526685830, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALQK4TLBSDMU3L2YT3EQUALXLGHH3ANCNFSM6AAAAAAUYRDMDY . You are receiving this because you were mentioned.Message ID: @.***>