• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 363 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.

CC1352P: SPI Data Size > 16 bits Not Supported?

Tim Simerly
Genius 9775 points
Part Number: CC1352P
Other Parts Discussed in Thread: ADS7054, CC3220SF

Dear Support:

I am interfacing the CC1352P1 to a SPI ADC (ADS7054) which needs at least 18 SCLK pulses between SPI transactions. However from reading the TRM, the SPI peripheral only supports data sizes of 8 and 16 bits.  Is that a problem with the hardware or the software?   Does this also apply to using the Sensor Controller when it uses the SPI in master mode?  As for using the main CPU, when I try to open the SPI port using a dataSize of 32, it fails with a bad handle - hence it does not support 32-bits as expected.  

Interestingly, the CC3220SF SPI peripheral does not have this restriction - it can support up to 32 bits.  Was hoping that these devices were using the same SPI peripheral.   If it is such that this is a hardware limitation with the SPI peripheral with the CC1352P1, do you have any suggestions as to how to get around this limitation?  I am the SPI port at 512 Kbps so don't want to have to have the CPU do bit-banging to fix this - need the DMA to move a block of data like 512 32-bit samples into memory per SPI transaction.  Your thoughts?

Thanks,
Tim

  • 0
    TI__Guru 58425 points

    Hi Tim,

    As you already figured out, the two device do not share the same SPI peripheral and the CC1352 only support frames up to 16-bit. My suggestion (I seem to remeber this have been done before) is to use 2x9-bit frame and remove the "minDMAThreshold" on the driver to make use of the DMA to create something re-assembling a "18-bit frame".

  • 0 in reply to IUsedToBeARealPerson (M-W)
    TI__Genius 9775 points

    Hey MW:

    Thanks for responding and your advice.  Per your advice, I need the SPI CS to toggle on an 18-bit frame size as below (Figure 37 in the ADS7054 datasheet):

    I then need to perform a transaction with a dataSize of 512 of these 18-bit values into memory.  Is this possible? 

    And what value do you recommend I use for the minDMAThreshold value for this to work.  However I am not clear what this value is and where it is located.  Do you mean the minDmaTransferSize that is in the SPICC26XDMA_HWAttrs structure?  If so, what should I set this value to?

    Thanks,
    Tim

  • 0 in reply to Tim Simerly
    Intellectual 290 points

    Tim I dont know if you considered this but you could remove the cs (chip select) pin from the spi block.  And manually toggle it yourself by hooking it to the gpio core instead.  Then the dma does all the work the cpu just does the toggling of the cs at the beginning and end.

  • 0 in reply to Myles Scott
    TI__Genius 9775 points

    Hey Scott:

    Thanks for your input here.  Yes, I had considered that but the problem here is that I have to take the CS signal active and inactive on every 18-bit data frame.  Hence the CPU would have to do this on every sample which is prohibitive since there are a lot of other processes running in parallel - some needing to run to completion without additional IRQs.  For every SPI transaction, I need to move up to 1024 samples into a frame and then process on this frame - without the CPU having to get involved in moving every sample.  I was hoping to create a frame of 32-bit samples and move the data into a frame of 16-bit samples and doing all this processing on frame boundaries and not sample boundaries.  From what I can tell, this doesn't look possible with a SPI peripheral that can only support up to 16-bit SPI data size - bummer.  Let me know if you think otherwise.

    Thanks,
    Tim

  • 0 in reply to Tim Simerly
    TI__Guru 58425 points

    Hi Tim,

    What Scott suggest is the simplest approach to this if you want to stay mode independent. That would however, as you say, result in a lot of CPU involvement in-between transfers. As the CS is required to get from AQC to CONV state, there is not nice workaround I'm afraid. 

    As for "minDmaTransferSize", yes that was the variable I was thinking of. It sets the limit for the number of frames you need to "transfer" for the driver to use DMA. Of you send below this number, a polling version is used. Setting it to 1 means you will always DMA.

    Are you already using the sensor controller? If not it do sound like it is a better fit here as you can make a 24-bit transfer (16+8) and toggle the CS in-between these. That way you would at least not need to worry about the CPU being busy doing other things. You could also pack the 14-bit value into 16-bits right away which means you should be able to fit a multi-buffer big enough for continuous transferring to the ARM core :)

  • 0 in reply to IUsedToBeARealPerson (M-W)
    TI__Genius 9775 points

    Hey MW:

    No I am not using the Sensor Controller for this and it does sound like the best solution here.  Thanks for all you advice and input on this on what to do.  It was very helpful.

    Thanks,
    Tim