ADSP-21569
Recommended for New Designs
Reaching speeds of up to 1 GHz, the ADSP-2156x processors are members of the SHARC® family of products. The ADSP-2156x processor is based on the SHARC...
Datasheet
ADSP-21569 on Analog.com
Back for the second episode of my series.
I have therefore expanded the project code illustrated in the first post of this series (here: SPI slave mode shifting 1s on MISO pin during adi_spi_DMARead() operation - Q&A - ADSP-2156x - EngineerZone) to get one step closer to the real-world application I'm going to develop.
In my application idea, master SPI is going to transfer N bytes to the slave, then slave SPI is going to transfer M bytes back to the master, all in a single transaction (by transaction I mean that, from SPI masters' point of view, the whole data exchange would be equivalent to a single transfer of N+M bytes).
To simulate this new scenario, I then applied the following changes to the code:
<--- in SPIDMAMode.h, replacing DESC_BUFFER_SIZE macro
<--- in SPIDMAMode.c
<--- new callback code
<--- changes in main() to pass SPI handlers as callback parameters.
Keeping SPI clock to around 1.3 MHz as in my previous post the result is exactly as expected:
but later when trying to raise clock frequency just a little bit to around 1.6MHz, this is what starts to happen:
clearly meaning that adi_spi_DMAWrite() inside Callback() is taking too long while disabling/enabling SPI slave peripheral.
This is what emerges by "looping the SPI dance forever" then analyzing the situation with statistical profiling:
So, the question is: how can I improve this behavior? There's no solution other than stop using ADI SPI driver and switching to a lower-level approach?
Thanks in advance to anyone who wants to contribute
Hi Nandini, happy to read you again even here 
> Could you please confirm if this is correct?
Yes, I confirm, your understanding of the scenario is correct.
> 1) Could you confirm whether the callback execution time is the same for both 1.3MHz and 1.6MHz SPI clock frequencies?
Measured 1 us latency @ 1.6 MHz, 0.9375 us latency @ 1.23 MHz. I measured it by means of a low speed logic analyzer, so I think that 62.5 ns time difference is probably more of a measurement error than a real latency difference.
> 2) Are there any error bits enabled in the SPI/DMA status register? Can you please share screenshot of register browser window.
I don't have the information about when you would like to see registers content, in the following you can see the content I captured at the end of the whole transfer (SPI1 read 8 bytes then wrote 2 bytes then I captured the registers content):
I don't see any error flag set, additionally Callback() is never invoked for events different from ADI_SPI_EVENT_TX_PROCESSED or ADI_SPI_EVENT_RX_PROCESSED so I were already almost sure that any error condition had been triggered.
> 3) Are the SPI modules properly disabled before being reconfigured for slave transmission and master reception?
Disabled? Why? You have to tell me the answer to your own question, since ADI code in adi_spi_DMAWrite() and adi_spi_DMARead() is in charge of disabling/enabling SPI peripheral and related while changing settings:
> 4) Just to ensure this behavior, is it possible to configure the API outside of the callback and check if the issue still persists.
Could you please clarify what do you want me to do? I can't fully understand what you mean, sorry.
Thanks in advance for your support
