• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1025 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.

TM4C1231H6PGE: Question on SSI1Fss behavor of SSI1 when used as SPI master

Richard Chen75
Intellectual 550 points
Part Number: TM4C1231H6PGE


Hi all, I just entered a post on this however it doesn't seem to be successful (the page loading never finishes and I had to cancel it), so I am going to enter it again here, my apology if it gets duplicated.

I am writing the following sequence to SPI bus via SSI1 module:

"

...

SSIDataPut (SSI1_base, 0x40);

SSIDataPut (SSI1_base, 0x0A);

SSIDataPut (SSI1_base, 0xA0);

"

But I am seeing that /CS line becomes HIGH then LOW between each byte, please see the attached picture, is it normal? Why as the transmit FIFO should be able to hold up to 8 bytes? I lowed down the SPI speed to 100KHz, it doesn't help. Is there a way to have SSI1Fss pin to stay LOW until all bytes are transmitted?

Thanks

Richard

  • 0
    TI__Guru*** 135355 points
    Hello RIchard,

    Yes that is normal operation for the TM4C /CS pin when left to be controlled by the SSI peripheral.

    If you want to force /CS to remain low throughout the duration of your transaction you should "manually" control the pin as a GPIO peripheral instead, this way you can force it low for the duration of your transaction by forcing it low before the first bytes are sent and pulling it back up to high when you are done transmitting/receiving.
  • 0 in reply to Ralph Jacobi
    Intellectual 550 points
    Ralph, thank you for the confirmation!

    Thanks
    Richard
  • 0 in reply to Ralph Jacobi
    Intellectual 550 points
    Ralph, what do I need to do in order to manually control the pin as a GPIO? Is it possible to enable SSI1CLK/SSI1Tx/SSI1Rx by enabling SSI module and independently reconfigure FSS1Fss as GPIO pin? Or I have to enable all 4 pins as GPIO?

    Thanks
    Richard
  • 0 in reply to Richard Chen75
    Guru 117855 points

    Richard/Ralph ... if I may.

    It is only necessary to initialize SPI: CLK, TX & RX as SPI.     You may initialize any convenient GPIO pin to serve as SPI Chip Select.   (then deploy that GPIO as Output)

    This provides the utmost in Control & flexibility of the Slave's chip-select - enhancing  your SPI operation...

  • 0 in reply to cb1_mobile
    Intellectual 550 points
    Thank you Cb1! so instead of doing the following:

    GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_3 | GPIO_PIN_2 | GPIO_PIN_1 | GPIO_PIN_0);

    I just need to do:

    GPIOPinTypeSSI(GPIO_PORTD_BASE, GPIO_PIN_3 | GPIO_PIN_2 | GPIO_PIN_0);

    the configure GPIO_PIN_1 (supposed to be SSI1Fss) to be a GPIO and let my code drive it separately?

    Thanks
    Richard
  • 0 in reply to Richard Chen75
    Intellectual 550 points
    Cb1, I would appreciate some example code on this if there is any, thank you!

    Richard
  • 0 in reply to Richard Chen75
    Intellectual 550 points
    My hardware design has already set SSI1Fss as the chip select, I can't use another GPIO pin as the result. Thanks.
  • 0 in reply to Richard Chen75
    Intellectual 550 points
    Cb1, I tried the following code, it appears to work, thanks for the help!

    Richard

    "
    // The SSI1 peripheral must be enabled for use.
    SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);

    // Enable GPIOD to use the SSI1
    SysCtlPeripheralEnable(KEY_SYS_PERIPH_PORT);

    // Configure the pin muxing for SSI1 functions on port D0, D2 and D3
    // This step is not necessary if your part does not support pin muxing.
    GPIOPinConfigure(GPIO_PD0_SSI1CLK);
    // GPIOPinConfigure(GPIO_PD1_SSI1FSS);
    // Config PD1 as GPIO!!
    GPIOPinTypeGPIOOutput(KEY_BASE_PORT, GPIO_PIN_1);
    GPIOPinConfigure(GPIO_PD2_SSI1RX);
    GPIOPinConfigure(GPIO_PD3_SSI1TX);

    // Configure SSI pin to be used properly
    GPIOPinTypeSSI(KEY_SSI_BASE_PORT, GPIO_PIN_3 | GPIO_PIN_2 | GPIO_PIN_0);
    "
  • 0 in reply to Richard Chen75
    Guru 117855 points

    Good for you Richard.     Do recall vendor Ralph's instruction - you must drive your GPIO to the (proper) Slave device's "CS" level - and maintain it there - until your "multi-byte data transfer" completes.    (I recall yours being 3 bytes long/24 bits)

    You could create a complete SPI transfer function - which would include  the normal "SPI Puts & SPI Gets"  - (sandwiched between) calls to that GPIO employed as Slave chip select.   (i.e.  your assertion of the CS signal is (both) the "first & last"  - step w/in your SPI  data-transfer function.)

    Note too that (many) here often "miss - or fail to adequately grasp" -  the fact that  "SSIDataGet()"  returns the data from the immediately preceding,  "SSIDataPut()."     Those two function calls must be "linked" (often back to back) - issuing an "SSIDataGet()" by itself will NOT succeed...

  • 0 in reply to cb1_mobile
    Intellectual 550 points

    Thanks again Cb1! You are simply awesome!!

    Regards,

    Richard