RX_READY, TX_PENDING, SPI issue

[kunalcha63]

Before you post

• [x] I confirm that I've read the guide on how to post issues
• [x] I confirm that I've consulted the wiki about my issue

Your Setup Platform: PEV Firmware Version: V01_00_07 Host Controller Interface: SPI Host: Own Implementation

Describe the bug SPI_TX_PENDING pin always asserted. SPI_RX_READY pin toggles during on-going transaction.

I can see this on UART logs after resetting Whitebeet. Not sure if this is related ? [ 9.746] [WARN ] APL-ETH: # Unhandled Ethernet notifycode 365

To Reproduce Note: We are meeting the CS pin timing requirements > 20us.

1. Reset Whitebeet. Check UART log and wait until init completes.
2. SPI_TX_PENDING is high. Start framing protocol on SPI [ size exchange + dataframe ]. Finish reading data from Whitebeet.
3. Start another transaction to read FW version.

Expected behavior SPI_TX_PENDING should go low after read complete. SPI_RX_READY should not change state during on-going transaction.

Logs

moxion_kunal_spi_issue2.sal.zip moxion_kunal_spi_issue.csv

• [x] If using SPI create a log file of the SPI traffic between host and Whitebeet. Currently Saleae Logic2 (preferred) and KingstVIS recordings are supported.
• [x] Create a log of the debug port (J11 UART) of the Whitebeet.
• [x] Attach the log files to this issue

Step 1: Reset Whitebeet. SPI_TX_PENDING goes high so host starts SPI framing protocol in step 2.

Step 2: Start reading from Whitebeet. Send size exchange frame , and correct size data frame.

TX_PENDING does not go low. Continue to read FW version in step 3.

Step 3: Send Size exchange frame, and correct size data frame for get FW version. TX_PENDING still high.

RX_PENDING goes high in middle of data frame transmission.

Step 4: Try to read response from Whitebeet. RX_PENDING goes high abruptly. TX_PENDING still high. Host tries to read size exchange bytes on MISO but identifier and payload size are incorrect.

Additional context UART capture :

APPLICATION: Name: ISO15118 (EV) Version: V01_00_07 Target: WHITE-BEET CPU: STM32F745

PRODUCT VERSION: String: SEVENSTAX_LIB_V_10_03_00 Hex: 0x000a0300 Dec: 100300

Hostcontroller Interface: SPI!

APPLICATION RUNNING ... [ 0.009] [NOTICE] SLAC: stxSLAC_Init()

[ 0.520] [NOTICE] APL-MAIN: BOOT-CFG: Boot QCA7005 firmware from host [ 0.521] [NOTICE] APL-MAIN: BOOT-CFG: FW2 [ 0.522] [NOTICE] APL-MAIN: BOOT-CFG: Module configured to EV [ 0.523] [NOTICE] PLCV-HL: Boot from host selected [ 0.523] [NOTICE] V2GCPS: stxV2GCPS_RegisterCallback() [ 0.533] [NOTICE] APL-ETH: Got link: [ 0.533] [NOTICE] APL-ETH: Interface: eth1 [ 0.534] [NOTICE] APL-ETH: MAC: C4:93:00:34:CD:44 [ 0.739] [NOTICE] PLCV-HL: Reset QCA700x [ 1.606] [NOTICE] PLCV-HL: ======================================= [ 1.606] [NOTICE] PLCV-HL: FW and PIB was loaded successful [ 1.738] [NOTICE] APL-MAIN: [ 1.738] [NOTICE] APL-MAIN: ============================= [ 1.739] [NOTICE] APL-MAIN: NEW LAN CONFIGURATION (IPv6): [ 1.739] [NOTICE] APL-MAIN: for IP Config handle [fe01] [ 1.740] [NOTICE] APL-MAIN: IPv6 Addresses: [ 1.741] [NOTICE] APL-MAIN: Link-Local: fe80:0:0:0 : c693:ff:fe34:cd44 [ 1.741] [NOTICE] APL-MAIN: Local: 0:0:0:0 : 0:0:0:0 [ 1.742] [NOTICE] APL-MAIN: DNS1: 2001:4860:4860:0 : 0:0:0:8888 [ 1.743] [NOTICE] APL-MAIN: DNS2: fd00:0:0:0 : be05:43ff:fe44:5280 [ 1.744] [NOTICE] APL-MAIN: ============================= [ 1.745] [NOTICE] APL-MAIN: [ 2.121] [NOTICE] PLCV-HL: ======================================= [ 2.122] [NOTICE] PLCV-HL: BOOT FROM HOST READY [ 2.292] [NOTICE] PLC-HL: Own PLC MAC = C4:93:00:34:CD:46 [ 9.746] [WARN ] APL-ETH: # Unhandled Ethernet notifycode 365

[kunalcha63]

@lho-stx or team: any update on this issue ?

[lho-stx]

Hey @kunalcha63,

thank you for the great description and the log files!

First of all the Unhandled Ethernet notifycode 365 is not related to the issue.

Unfortunately I do not have any conclusion yet. I haven't seen this behavior before. The TX pending pin should go low as soon as the transmission finished. As it keeps high there are more frames to read from the WHITE Beet, but the size exchange frame of the WHITE Beet is already wrong (0x55 0x55 instead of 0xAA 0xAA).

The only thing that differs to my reference log file I can spot right now is, that the RX ready pin is de-asserting before your host is de-asserting the chip select. As this is done by the WHITE Beet it seems the software is in a confused state.

I kindly ask you to do the procedure described in 10.2 Recovering from Synchronization Errors in the WHITE Beet manual right after the first framing message received. Please send me the .sal file of this.

Best regards, lho

[kunalcha63]

@lho-stx Attached sal file for recovering via ping mechanism every 50ms. Only the initial SPI transaction for status message "interface up" after reboot works as previously. All subsequent comms are out of sync. Also tried waiting for suggested time > 200ms from 10.2 Recovering from Synchronization Errors . Did not see the expected results. ping.csv ping_recovery.sal.zip

As we are integrating Whitebeet chip on custom HW, do you have any HW related design suggestions/guidelines to be followed. Thank you.

[lho-stx]

Hi @kunalcha63,

thank you for the logs, I will check them.

For HW related questions please contact CODICO, as this issue tracker focuses on the V2G protocol and Framing communication.

Best regards, lho

[kunalcha63]

@lho-stx thanks, will do.

One more question ; although not related to this ticket. I don't see module/service related to proximity pilot signal. Is this feature not implemented yet ?

[lho-stx]

Hey @kunalcha63,

this is out of scope of the current WHITE Beet software, I am sorry.

Best regards, lho

[lho-stx]

Hey @kunalcha63

I can not see any reason for the WHITE Beet behavior in the log files. Did you already have contacted CODICO? I also can not reproduce the error with my setup. Is it possible for you to use a RaspberryPi as host controller? Like in this guide??

Best regards, lho

[github-actions[bot]]

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]]

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!