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.

RTOS/SIMPLELINK-CC2640R2-SDK: one SPI object, two slaves, single task

Part Number: SIMPLELINK-CC2640R2-SDK

Tool/software: TI-RTOS

Hi, I am using SDK 1.40.

I have modified the simple_peripheral project to include two SPI devices in parallel, their hardware interrupts are dispatching events to the main application task. The SPI is configured in callback mode and the

sempahore is not posted until the transaction is complete. Each slave has their own SPI chip select. Now the whole process of CS=0->transaction-CS=1 is guarded yet by another global mutex semaphore, to ensure

that  only one slave is serviced at a time. The initalization stage works fine for both devices, the problem arises when the interrupts are enabled, whoever gets serviced first will own the SPI bus forever, with the other

device blocked out.

The interrupt works correctly when only one of the devices is present, I can switch between which one will own the bus by manualy switching the respective IRQ PIN. I should mention that the interrupt routine is

clearing the interrupt flag and then reading some values from the devices register.

Instead of a hardware ISR I have moved the routine to be triggered by a periodic clock - same result. No other devices are present. If I move one of the devices to the other SPI bus, they can work side by side, the

problem is only with them working from one bus in parallel. Hwi stack is 1024 with peak around 500. Increasing the advertisment interval or connection does not influence the behaviour.

I can just use two buses - it is not a problem - I am just courious what is going on. Could this be a hardware related problem with the parallel connection or the fact that these are triggered from the same task

context?

Cheers

  • With problems like these a logic trace would be immensely helpful.

    With the setup you have, you definitely do not want to use the (hardware chip select pin) .csnPin in the SPI driver's hardware attributes (see the SPI_config[] structure). You need to provide an additional mutex along with the GPIO pins you are using as your chip select.

    mutex enter
    set CS
    SPI_transfer
    clear CS
    mutex leave