CC1310 latest RTOS SPI problem

Sorry for the long delay. I will look into this and get back to you as soon as possible.

Dear Riccardo,

please provide more information about the communication setup:

• How many bytes are sent during a single transfer?
• What is the time between two transfers?
• Do you use the UART in blocking mode? Remember that the SPI callback runs in software-interrupt context.
• What do you mean by loop? Do you mean that multiple callbacks are stacked?

Please test the following:

• Remove any potentially long-running activity from the callback such as UART_write().
• Use the debugger and a counter variable to find out whether your callback is stacked.

Hi Richard,

thanks for your reply, my scenario is the following:

1) CC1310 as SPI slave, I start a transition with 100 bytes, tx and rx buffers and RETURN PARTIAL enabled.

2) I send packets from my raspberry with variable len, determinated by the CS deassertion, for this reason I enabled the RETURN PARTIAL features on the CC1310

I haven't any UART_write in the callback function, I checked and discovered the problem using the debugger. When I start a single transmission from the raspberry, the cc1310 enters in the callback function,executes code and exits from the callback setting a new transition,but instead wait for a new transiction from the master, it reenters again in the callback, and this forever.

If I turn off the RETURN PARTIAL features (sending the whole 100 bytes from the raspberry) all works fine, but I have to use fixed len packets so.

If I don't go wrong, with the previous RTOS release this problem doesn't exist, but I can't downgrade now for strict time reasons.

Riccardo

Hi Richard,

any news on this problem?

Thanks

Riccardo

Riccardo,

sorry, I haven't had the time to replicate your setup, so I have to bother you with more questions. Let's first look at the most obvious things. Can you please find out:

• What is happening when the program blocks? Does an exception occur? You can check that in the ROV viewer (Screenshot 1). Please also have a look into "BIOS" -> "Exceptions".
• Or do you maybe observe a stack overflow? Check the stack peak vs the stack size for your task and for hwi. 

I guess that the SPI transaction is declared as global variable, isn't it.

FYI: We found a bug in the TI-RTOS SPI driver. It is even present in the current releaese 2.20 and will be fixed in 2.20.1, probably by end of August.

In the meantime, you can try the following:

• Copy SPICC26XX.c into your project directory
• Replace the function SPICC26XXDMA_csnCallback() with the below content

static void SPICC26XXDMA_csnCallback(PIN_Handle handle, PIN_Id pinId)
{
    SPICC26XXDMA_Object        *object;
    SPI_Handle              spiHandle;
    PIN_Config              csnConfig;

    /* Get the pointer to the SPI object */
    spiHandle = (SPI_Handle) PIN_getUserArg(handle);
    object    = spiHandle->object;

    /* Get current CSN config */
    csnConfig = PIN_getConfig(object->csnPin);

    /* Disable all interrupts */
    PIN_setInterrupt(handle, object->csnPin);

    /* Cancel transfer if POSEDGE interrupt */
    /* TODO: Consider doing this in a SWI */
    if ((csnConfig & PIN_IRQ_POSEDGE) == PIN_IRQ_POSEDGE) {
    
        /* Indicate why the transaction completed */
        if (object->currentTransaction != NULL)
        {
            object->currentTransaction->status = SPI_TRANSFER_CSN_DEASSERT;
        }

        /* Cancel the current transaction */
        SPICC26XXDMA_transferCancel(spiHandle);
    }
}

Let me know if this fixes your issue.

I'm coming from here( e2e.ti.com/.../1941980 ). I am experiencing the same issue as the O.P. in that thread, except that I'm using blocking mode instead of callback. I attempted this, but this did not fix my issues. It is indeed calling into the copied .c file ( I verified with the debugger ) but I still am getting a 5/6:1 error:success transmitting a 3 byte frame. After reviewing the .c file, I am wondering if this is an H/W issue with the SPI peripheral?

Hi Michael,
I don't see how the problem that you describe in e2e.ti.com/.../1941980 is related to the problem described in this thread. Please proceed in e2e.ti.com/.../1941980.