AM6442: MCSPI delay between transfers

Hi Tobias,

I am assuming you have gone through the MCSPI Performance numbers for the processor AM64x: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_00_00_15/exports/docs/api_guide_am64x/DATASHEET_AM243X_EVM.html#autotoc_md529

Please read the comments about the HW time being added as well.

Looks like the time which is added by the hardware is about 190 nanoseconds which would be a small number compared to the bigger delay which you have mentioned: 50 microseconds.

Can you also let me know, if your requirement is to run the SPI interface as the third option(Single Peripheral) mentioned here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1414084/faq-sk-am64b-mcspi-integration-guide/5428405#5428405

Or you want to run the SPI interface as the Single Controller/Multi Controller.

Tobias said:

We are experiencing delays between SPI transfers,

Do you mean to say that the time T is high of about 50 microseconds?

First Transfer on the wire is seen via logic analyzer

Time Taken T

Second transfer on the wire is seen via logic analyzer

Regards,

Vaibhav

We run it as a Single Peripheral. I have not looked at it with a logic analyzer yet but will do as soon as i have one.

What i can see is that the Controller after a transmit have to wait for at least 50 microseconds before it transmits again. If it don't wait for such a long time the Peripheral breaks down.  

The Controller will send data continuous to the Peripheral so we can not have delays like that (not sure how big delays we can live with but 50us is too much).  

So this is what i have to do on the Controller to make the Peripheral work:

-First Transfer.

-Wait 50us or else the Peripheral gets left behind and stops working as expected.   

-Second transfer on the wire.

-Wait 50us or else the Peripheral gets left behind and stops working as expected.   

-Third transfer on the wire.

--And so on ...

I understand that a wait is needed its just that 50us is too long for our use case. 

Hello Tobias,

Thank you for clarifying that the peripheral is configured on our Sitara Processor.

On that note, I have also understood the flow which you have mentioned below:

Tobias said:

-First Transfer.

-Wait 50us or else the Peripheral gets left behind and stops working as expected.   

-Second transfer on the wire.

-Wait 50us or else the Peripheral gets left behind and stops working as expected.   

-Third transfer on the wire.

--And so on ..

I need to understand what kind of wait is this.

Is this a sleep of 50 microseconds on the Peripheral side in the following manner:

1. MCSPI Parameters Initialization
   
   Is wait 50 microseconds introduced here?
   
   
   
2. MCSPI_transfer()
   
   Or after MCSPI_transfer completes the 50 microseconds is introduced?

Regards,

Vaibhav

I'm developing both a Master and a slave. The Master is used to test the performance of the slave. The delay is put into the Master (I'm trying to make that delay as small as possible and ended up at 50us). I get back with some more information next week (some other things suddenly got more important). I'm basically trying to figure  out if I have to write a driver or not. 

Hi Tobias,

Tobias said:

The delay is put into the Master

Thanks for mentioning this, it would be really helpful if this information is more detailed. For example, from the drivers itself, can you point out to the Code/API where you are introducing this delay of 50 microseconds?

Regards,

Vaibhav

Hi,. after some more investigation i realized that the delay is very small (not 50us).  

What approach do you recommend for reading continuous data?  

Hi Tobias,

Tobias said:

Hi,. after some more investigation i realized that the delay is very small (not 50us). 

Glad to know about this.

Tobias said:

What approach do you recommend for reading continuous data?  

My recommendation to reading continuous data is as follows.

I understand that the MCSPI is configured as a Single Peripheral, but lets assume that the MCSI was configured as a Single Controller.

In this case, where MCSPI is a controller and we want to read continuous data from the external Peripheral, a good configuration on our SW code would be to set MCSPI_TRANSACTION_PARAMETER.csDisable to FALSE.

What this does is keeps the chip select low between the Controller and the Peripheral and hence continuous MCSPI_transfers are called.

So a similar implementation can be looked forward to your Controller interacting with our MCSPI Peripheral.

Regards,

Vaibhav

Thank you. I have one more question.

I'm reading the Technical Reference Manual chapter 12.1.4.5 MCSPI Programming Guide. If i understand it correctly the concept of a transaction is not only a software concept but it is also part of the hardware (at least when using DMA). With transaction i mean that the system have to know the size of the data before it receives/transmits. Note that i don't have any problems i just want to know how it works. 

We are trying to figure out if the fpga (developed in house) shall stream data or if it should send it in chunks to the sk-am64b. If the SPI hardware is working with transactions then we don't have to put any effort into trying to stream.

Regards

Tobias

Hi Tobias,

Tobias said:

also part of the hardware (at least when using DMA)

I understand that you read this information from the TRM. Can you please highlight this exact section for me to consume the same.

Tobias said:

If the SPI hardware is working with transactions then we don't have to put any effort into trying to stream.

I can comment on this once I have read that specific section from MCSPI Programming Guide.

Looking forward to your response.

Regards,

Vaibhav