DRA821U-Q1: DRA821 MCSPI1 transaction to transaction delay issue

Syed N Akhtar

Part Number: DRA821U-Q1
Other Parts Discussed in Thread: DRA821, DRA829

This is a continuation of previous E2Epost: DRA821U: DRA821 MCSPI1 transaction to transaction delay time is too long - Processors forum - Processors - TI E2E support forums

We have two customers complaining about the same issue. They can't use DMA for this application. They have increased the data throughput to the max already.

The customers are still seeing 3.5us delay between each SPI transactions between Hydra board DRA821 processor and carrier FPGA.

We plan on testing SPI bus on DRA829 Eval board to confirm that the limiting factor is not the VxWorks SPI driver. But I am hoping that TI team can help share any SPI test data and scope captures (if they have any) to show that that such delays are not expected and are not due to limitation of DRA821 internal bus structure.

I will appreciate if your team can provide support on this issue as it is impacting customers' integration schedule. Can TI team help perform SPI test on the DRA829 Eval board?

3 days ago

0 Takuma Fujiwara 3 days ago

TI__Guru 52873 points

Hi Syed,

How is the McSPI interface being used? Is it one large block of data being transferred, or multiple small transactions that are sent frequently? (and if small, how large is each transaction?)

Regards,

Takuma

0 Luke 1 day ago in reply to Takuma Fujiwara

TI__Expert 3920 points

Hi Takuma,

For information, we have 2 different use cases. In both the cases, DRA821 SPI is interacting with memory on an FPGA.

Bulk memory update:
Data is being written to contiguous memory locations and the total amount of data to be written is large.
For this use case, both the teams have already implemented the suggested workaround for reducing the overhead by using long data frames.
Asynchronous memory update:
Small amounts of data being written to different addresses, 4 to 8 bytes. There is not a lot of scope to optimize these further.

To address the second use case, team was able to modify the driver to not re-configure SPI peripheral for back-to-back transactions. With the changes in place, only a few (I think 2, I can check) registers are being written to between 2 transactions. This still leads to 3-3.5us delay between transactions (measured between chip selects).

Are other customers facing similar challenges? Are there any mitigation actions/workarounds we can look into?

Best,

Luke