RX_READY, TX_PENDING, SPI issue
Closed this issue · 9 comments
Before you post
- I confirm that I've read the guide on how to post issues
- 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.
- Reset Whitebeet. Check UART log and wait until init completes.
- SPI_TX_PENDING is high. Start framing protocol on SPI [ size exchange + dataframe ]. Finish reading data from Whitebeet.
- 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
- If using SPI create a log file of the SPI traffic between host and Whitebeet. Currently Saleae Logic2 (preferred) and KingstVIS recordings are supported.
- Create a log of the debug port (J11 UART) of the Whitebeet.
- 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.010] [NOTICE] APL-ETH: MAC of NIC[0]: c4:93:00:34:cd:45
[ 0.520] [NOTICE] APL-ETH: MAC of NIC[1]: c4:93:00:34:cd:44
[ 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
@lho-stx or team: any update on this issue ?
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
@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.
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
@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 ?
Hey @kunalcha63,
this is out of scope of the current WHITE Beet software, I am sorry.
Best regards,
lho
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
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.
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!