This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2642R: SPI Callback delay in Master and Slave mode and parallel SPI transactions issues

Part Number: CC2642R
Other Parts Discussed in Thread: SIMPLELINK-CC13XX-CC26XX-SDK, SYSCONFIG

Hi,

I am trying to use 1 of the SPIs on the MCU to send commands to an ADC and I receive data back using another SPI as slave

I am experiencing the following issues:

1. Master SPI transaction timing takes longer than it should,  the Master clock is set to 6M and I am sending 76 bytes, the transfer (looking at the clock pin) takes about 110us, however, the time between initiating the transfer up to receiving a callback takes extra 32us, why is that ? and if this is a normal behavior, do i need to wait for the callback to be received to get the data and send new transfers?

in the following picture in blue (CS pin) in red GPIO turned on before the transfer and off first thing inside the spi callback

 

2. the data is send t through a fiber optic cable and received back with a small delay, and we have to send back the clock and cs with the MISO data to compensate that delay and all this is recieved by a slave SPI 

the slave transfer is initiated before the Master, and slave callback is received most of the time before the callback of the master, however, it happens too frequently that the callback does not return at all and everything crashes after a short while 

what i am trying to do is send 76 bytes with the MASTER SPI and receive back 76 bytes using the slave SPI every 200us which I am not able to do 

  • Hi Jameel,

    What SIMPLELINK-CC13XX-CC26XX-SDK version are you evaluating?  Are you also using a radio stack consecutively?

    1. Can you please provide simple sample code based on spicontroller to demonstrate what you are attempting to accomplish?  Is behavior improved when using blocking mode, and have you tried queueing transactions in callback mode? 

    2. If there are additional configurations available from the peripheral then it could be optimal to implement "peripheral ready" and "controller ready" GPIOs to synchronize the two devices.

    Please refer to the following for generic examples and SPI TI Driver information:
    https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_10_00_98/docs/drivers/doxygen/html/_s_p_i_8h.html 
    https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_10_00_98/docs/drivers/doxygen/html/_s_p_i_c_c26_x2_d_m_a_8h.html 

    Regards,
    Ryan

  • Hi Ryan,

    This is an old project and I'm using simplelink_cc13x2_26x2_sdk_5_20_00_52, I am trying to port my code to the latest SDK but I'm facing some issues with the linker.

    1. I did try queueing transactions with no improvement, Blocking mode is not an option here as I am trying to work with master and slave together at the same time 

    here's a diagram of what i want to do 

    the slave would need to work with the cs and clock that are generated by the master and travelled all the way to the ADC through Fiber optic cable delay and SerDes delay and back. that is why the slave needs to initiate the transfer and wait then master sends it's transfer. 

    I tried only blocking the master transfer but no luck either, everything stops after few transfers 

  • Thank you for providing the visual, it certainly helped me understand your setup.  What linker issues are you experiencing?  I recommend starting with a default project from the v7.10 SIMPLELINK-CC13XX-CC26XX-SDK and moving over the application changes.  Is the 32us delay dependent on the callback from SPI0 or SPI1?  So you have tried to use SPI0 in blocking mode and SPI1 in callback mode?  What are the SysConfig SPI settings and SPI initialization parameters, and is the radio active as well?  Is the device not responsive after the transfers stop and can you debug this crash state?

    Regards,
    Ryan