• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 529 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/CC3220SF-LAUNCHXL: SPI master POL and PHA

Riccardo Cardinali
Expert 1125 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, CC3200

Tool/software: TI-RTOS

Hi all,

I'm interfacing an epaper displey that works with SPI interface, the required data format is 8 bit frame, POL = 1 and PHA = 1. I set the SPI1 of the CC3220SF to obtain this, but it doesn't work, in the specific, doing some test I discover that the CS (active low) is asserted and deasserted every byte instead every packet transfer.

On the datasheet is confirmed that with POL = 1 and PHA = 1, the CS is asserted on the start of the entire packet (100 byte for example) and deasserted on the end. Is need any other registry setting to obtain this? I'm using HW CS by uDMA. I  have try to use a GPIO set with the GPIO_write function and the communication works great, it seams a bug on the SPI driver using HW CS by uDMA.

Thanks

Riccardo

  • 0
    Expert 1125 points
    Hi all,

    I saw that in the spi folder inside ti/drivers, there is a DMA version of the driver, have I to use this one version? Currently I'm using the spi.h inside ti/drivers, I suspect that this is the main problem. In the DMA version code I saw the funcion SPICSDisable and SPICSEnable, non available in the spi.h file. Can you confirm this ? Any example on DMA SPI master code?

    Thanks!
    Riccardo
  • 0 in reply to Riccardo Cardinali
    TI__Mastermind 45216 points
    Hi Riccardo,

    If you are wanting to use the micro DMA controller for SPI then yes you should use that driver.

    There's some good documentation on the SPI drivers in the SDK, see below:

    C:\ti\simplelink_cc32xx_sdk_1_60_00_04\docs\tidrivers\doxygen\html\_s_p_i_8h.html
    C:\ti\simplelink_cc32xx_sdk_1_60_00_04\docs\tidrivers\doxygen\html\_s_p_i_c_c32_x_x_d_m_a_8h.html

    As for DMA SPI master code, I don't believe the SDK has any available right now. I see some previous E2E posts of people that have implemented this with CC3200 which you could maybe utilize. Some of the users have seemed to put their findings/code on github as well if you'd like to search there and port what you need.

    e2e.ti.com/.../402221 ==> Uses CC3200 as slave I believe

    Hope this helps,
    Kevin
  • 0 in reply to Kevin Allen18
    Expert 1125 points
    Hi Kevin,

    sorry but I'm little confused: I check the documentation on line and I saw that the SPI.h is the API that is interfaced to more device specific drivers, in my case the CC32xx driver, so these APIs should be transparent compared to the device. Now this means that if I use the SPI.h automatically I'll use the specif device driver (CC32xx), with all its features. My problem is that I should force a specif driver aspect about the CS assertion and dessertion (I need CS enable at the start of a multiframe packet and CS disable only at the end of the packet, now the driver assert and deassert CS every single byte), is this possible, or the best think is use SPI only for data and clock, managing manually the CS with a GPIO_write function before and after the SPI_transfer? To obtain this, I have to set the CS PIN assignment in the SPICC32XXDMAHWAttrs to SPICC32XXDMA_PIN_NO_CONFIG. Another solution could be set the SPICC32XXDMAHWAttrs.csControl to SPI_SW_CTRL_CS, but after which is the function to assert and deassert the CS by software?

    Thanks again
    Riccardo

    P.S. the example code from github you reported to me is all written using low level functions (MAP_ etc),not using the SPI.h APIs.
  • 0 in reply to Riccardo Cardinali
    TI__Mastermind 45216 points
    Hi Riccardo,

    Sorry for taking a while to get back to you.

    The drivers are too high level to change how it handles CS during transfers, I.E. changing how many bytes CS is high/low. I think you have the right idea of driving the CS by a GPIO. I believe setting SPICC32XXDMAHWAttrs.csControl to SPI_SW_CTRL_CS makes the controller only use SIMO, SOMI, and SPICLK and it won't touch CS.

    Best,
    Kevin