• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 750 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1350: Issue running DMA with both SSI peripherals simultaneously.

Grant Fritz
Prodigy 30 points
Part Number: CC1350

I'm currently trying to run both SSI peripherals on the CC1350 at 12MHz and am running into an issue where the DMA is only servicing SSI0 and barely servicing SSI1. The transaction for SSI1 returns that it has been processed but with a logic analyzer, there's almost nothing that's transacted across the bus. Mainly there are large wholes in the data being transacted. I understand that SSI0's DMA takes priority over SSI1 which makes sense why SSI0 has priority. But does the DMA controller only have the ability to service one peripheral at a time and is just time slicing the transfers? Would "burst mode" help this some by making the DMA not monopolized by the constant pestering from a higher priority channel (SSI0)?

Also, I only need one SSI to transmit and one SSI to receive but it seems that with the default TI API from Simplelink SDK 1.60.00.21 you have to initialize both the RX and TX DMA when performing a transfer. I don't know if that might make this work out 

Any help on how to configure the SSI's to perform simultaneously would be greatly appreciated.

Thanks,

Grant

  • 0
    TI__Guru 58425 points

    Hi Grant,

    Could you provide some more information on how your system is setup so that I can try setting up a test case for it?
    Are both SSI0 and SSI1 running as master or is any of them running in slave mode?

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 30 points

    Hey,

    I have my system with an external ADC module on SSI0 and is running with a 12MHz clock with 48 byte long transactions (48 bytes coming into the CC1350, no TX) happening 9600 times a second. On SSI1 there is an external SPI Flash running at 12MHz clock with a 2048 byte page transaction (2048 bytes being transmitted in two 1024 chunks from the CC1350 with a few bytes received) happening 228 times a second. Both SSI0 and SSI1 are configured as masters to their attached peripherals. Each set of SSI code has it's own thread in TI RTOS (adc thread, flash thread).

    What I'm seeing:

    If the ADC transactions are disabled, the flash transactions are full 2048 byte pages happening at the expected interval. (first 1024 bytes are supposed to be 0's)

    If the ADC transactions are enabled, the ADC transactions looks correct with the data being clocked back correctly. The flash transactions are only around 800 bytes instead of 2048. It appears as if there are wholes in the data being clocked to the flash where the ADC data is being received (adc ssi clock is Channel 5).

  • 0 in reply to Grant Fritz
    TI__Guru 58425 points

    Thanks for the detailed presentation, there seem to be something fishy going on here.

    When you get the transaction callback (assuming you use SPI in callback mode), what is the transaction status of the SSI1 transaction?
    What I want to figure out is if the SSI1 transaction (for some reason) gets canceled by the driver, as this is the only way I can find that would impact the DMA transfer.

    If you have the possibility to put a breakpoint inside the driver (SPICC26XXDMA.c) to check for this as well it would be great.
    A good placement is inside the "SPICC26XXDMA_hwiFxn" function, just inside the "if (intStatus & SSI_RXOR) {" statement.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 30 points

    Your hunch is correct, the SPI transfer is being cancelled because of an RX Overrun. It hits inside that if statement in "SPICC26XXDMA_hwiFxn" with the SSI_RXOR bit set. The transaction is then canceled without all the data being transferred. 

    Can you think of a way to get around this? For this specific transaction, I don't actually care about the received data, I only care about the transmitted data. 

  • 0 in reply to Grant Fritz
    TI__Guru 58425 points

    I have been able to reproduce the problem and I'm looking into what can be done about this.

    I'll get back to you when I got any updates.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    TI__Guru 58425 points
    Update:

    What seems to happen is that if the SSI1 DMA manages to fill up the TX FIFO with 8 + 1 bytes (1 in output register, 8 in FIFO) and then gets blocked by the SSI0 DMA, preventing the SSI1 DMA from reading out any data. At the same time, the SSI1 module transfers empties the FIFO, resulting in 9 bytes being read and the SSI1 RX FIFO getting an overrun.

    What you can try in order to mitigate this is to lower the size of the DMA TX burst, this is done by lowering the numbers of arbitrated bytes the DMA uses for the TX channels. I lowered the number from 4 to 2 bytes and was able to run both interfaces at 12 MHz.

    You can try this fix out by adding the SPICC26XXDMA.c driver source to your project and then change the "dmaTxConfig" array found at the top. In this array, Change "UDMA_ARB_4" to "UDMA_ARB_2". Let me know if this works for you!