SPI Interface Issue - Module-EI, Module-PI about freev2g HOT 10 CLOSED

Hi,
for me it looks like there is a problem with the chip select timing. Maybe the 20 µs mentioned in the Whitebeet manual do not fit anymore.

Could you please try to increase the interval from chip select low to the start of data transmission (CLK) to 40 µs.
I suspect that this will fix the problem.

from freev2g.

Hi @bbr-stx

[Module-PI]
I followed your suggestions about the interval from CS low to the start transmission and set up to almost 65 us.

[Test - Get firmware version Command]
Host controller sent size frame: 0xAA, 0xAA, 0x00, 0x08
Module-PI response: 0xAA, 0xAA, 0x00, 0x00

Host controller sent data frame: 0x55, 0x55, 0x00, 0x00, 0xC0, 0x10, 0x41, 0x02, 0x00, 0x00, 0x00, 0xC1
But module-PI response: 0x55, 0x55, 0x00....... 0x00 (All 0x00)
I think the expected data will return the hex number of firmware version .

Do I set the wrong data ? or do you have some suggestions about this issue ?

JoeChen

from freev2g.

Hi,

please note that the response from the module is not in the same SPI transfer. After the SPI transfer (0x55, 0x55, 0x00, 0x00, 0xC0, 0x10, 0x41, 0x00, 0x00, 0x00, 0x00, 0xC1) you should notice that the TX pending pin goes high which means that the Whitebeet has a frame for the host.

To retrieve the response from the module please follow the steps below:

1.) Just send a frame with length 0 (AA AA 00 00) via SPI to the module and then read from MISO how many bytes the module wants to send to the host. For example you receive 'AA AA 00 13' from the host. This means that the Whitebeet module has 19 bytes of data which must be read out.

2.) For receiving the answer now, you have to send the SPI data exchange frame with the requested length from host (in this case 19 bytes). So the host has to start the next SPI transfer with the following data '55 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'. On MISO line you will receive the answer for your request. For example '55 55 00 00 C0 10 41 00 00 0B 00 09 56 30 31 5F 30 30 5F 30 34 DC C1' (V01_00_04).

I hope the information helps you.

from freev2g.

Hi @bbr-stx

It works and thanks for the information !

There are two questions about the SPI interface.

1. The host controller needs to transfer four sets of data so host could get correct data from slave. Why it designed this way ? Why not just two sets of data only ?
   [Example for sending data by host]:
   (First data) 0xAA, 0xAA, 0x00, 0x08
   (Second data) 0x55, 0x55, 0x00, 0x00, 0xC0, 0x10, 0x41, 0x02, 0x00, 0x00, 0x00, 0xC1
   (Third data) 0xAA, 0xAA, 0x00, 0x00
   (Fourth data) 0x55, 0x55, 0x00, 0x00 .... 0x00

2. It seems that the example demo of SPI interface transfer size and data frame in user manual (Refer to 9.2.7). But it didn't mention how host get data after TX pending pin goes high. If I miss the details of the user manual, please feel free to tell me!

Thanks for your support!
BR.
JoeChen

from freev2g.

Hi @bbr-stx

Currently we test module-EI in SPI interface and meet some problem about TX_PENDING pin.

After booting the module-EI, host sent the command(Get firmware version) and host received the correct data.

But when sending the same command above twice, TX_PENDING remained high and host couldn't get the correct data.

Do you have some suggestions about the TX_PENDING pin of module-EI ?

Thanks.
BR.
JoeChen

from freev2g.

Hi JoeChen,

why the pin remains on high I can't say unfortunately. What do you receive when you read more frames from the SPI?

Could you please show the exact sequence of frames that are sent to the Whitebeet module, including the responses from the module?

BR

from freev2g.

Hi @bbr-stx

we are logging two logs for this problem, one is PI module uart log another one is logic analyze file, you can install Acute software to view this file, link is "https://www.acute.com.tw/images/Software/LA27874b.zip".
In PI module have any initial sequence or steps command needed to execute when the host uses the spi interface?

Please refer to the attachment.
EI_log.zip

Thanks.
BR
JoeChen

from freev2g.

Hi @bbr-stx

Any updates for the previous comment?

By the way, I want to ask some questions about SPI interface.

1. The host controller needs to transfer four sets of data so host could get correct data from slave. Why it designed this way ? Why not just two sets of data only ?
   [Example for sending data by host]:
   (First data) 0xAA, 0xAA, 0x00, 0x08
   (Second data) 0x55, 0x55, 0x00, 0x00, 0xC0, 0x10, 0x41, 0x02, 0x00, 0x00, 0x00, 0xC1
   (Third data) 0xAA, 0xAA, 0x00, 0x00
   (Fourth data) 0x55, 0x55, 0x00, 0x00 .... 0x00

2. It seems that the example demo of SPI interface transfer size and data frame in user manual (Refer to 9.2.7). But it didn't mention how host get data after TX pending pin goes high. If I miss the details of the user manual, please feel free to tell me!

Thanks!
JoeChen

from freev2g.

Hi @Joenoodoe,

thanks, with the help of the log I found out why the Tx pin stays high.

Before the third SPI transfer (size+data) was sent the Whitebeet module already wanted to transfer data to the host and therefore it set the Tx pin high.

In the third SPI transfer the module asks to send 9 bytes in the Size Header, but only 8 bytes (which were announced by the host) are read in the following SPI transfer, but the host must read 9 bytes from the module in this case.

Here the data from the log:

MOSI: AA AA 00 08
MISO: AA AA 00 09

MOSI: 55 55 00 00 C0 10 41 01 00 00 00 C1
MISO: 55 55 00 00 C0 05 81 FF 00 01 00 F5

Due to the missing byte during SPI transfer the communication is disturbed and the synchronization is lost.

However, the SPI transfer should have looked like this:

MOSI: AA AA 00 08
MISO: AA AA 00 09

MOSI: 55 55 00 00 C0 10 41 01 00 00 00 C1 00
MISO: 55 55 00 00 C0 05 81 FF 00 01 00 F5 C1

To avoid this problem:

1. The host has to take care that during the SPI data transfer it also has to take care if and how much data the Whitebeet module wants to send to the host.
2. The host should read pending packets as soon as possible from the module if the Tx pin goes high. The host can also indicate that it does not want to send any data by itself.

I think if this is observed there should be no problems with the transfer.
Furthermore we will describe this topic in more detail in the Whitebeet manual.

from freev2g.

I assume that the problem has been fixed by now. If the problem is still not solved, you are welcome to reopen the ticket.

from freev2g.