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.

EK-TM4C123GXL: SSI initialisation

Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: TM4C123GH6PM, SW-TM4C

Hello ,

I am trying to initialize the SSI peripheral by writing my own drivers. I am using the EK-TM4C123GXL eval board. The port used is the SSI0. These are mapped onto pins - PA(5:2).

The code is as stated below -

  1. #include <tm4c123gh6pm.h>
  2.     #include <stdint.h>
  3.     
  4.     #define LED_RED 0x02
  5.     #define LED_BLUE 0x04
  6.     #define LED_GREEN 0x08
  7.     void main(void) {
  8.     
  9.         // initialise SPI bus //
  10.         // PA(2:5) -
  11.         // PA(2) - SSI0CLK
  12.         // PA(3) - SSI0Fss
  13.         // PA(4) - SSI0Rx
  14.         // PA(5) - SSI0Tx
  15.            
  16.         
  17.         int countTest = 0;
  18.         
  19.         // -- SPI initialisation -- //
  20.         
  21.         // SPI CLOCK FOR SSI0 //
  22.         
  23.         SYSCTL_RCGCSSI_R = 0;
  24.         SYSCTL_RCGCSSI_R |= 1;
  25.         
  26.         // GPIO_A clock //
  27.         SYSCTL_RCGCGPIO_R  = 0;
  28.         SYSCTL_RCGCGPIO_R  |= 1;
  29.         
  30.         GPIO_PORTA_PCTL_R  = 0;
  31.         GPIO_PORTA_PCTL_R  = 0x00222200;
  32.         
  33.         //GPIO_PORTA_AFSEL_R = 0;    
  34.         //GPIO_PORTA_AFSEL_R |= 0x3C;
  35.         
  36.         //GPIO_PORTA_DEN_R   = 0;
  37.         //GPIO_PORTA_DEN_R   |= 0x3C;
  38.         
  39.         // SSI is disabled //
  40.         // Maybe an if-else needed to check if enable is set //
  41.         SSI0_CR1_R &= 0;
  42.         
  43.         // SSI configuration //
  44.         
  45.         SSI0_CR1_R |= 1;         // - loop-back enabled //
  46.         SSI0_CPSR_R = 0x00000002;
  47.         SSI0_CR0_R = 0x000009C7;
  48.         SSI0_CR1_R |= 2;
  49.         
  50. //         
  51. //         
  52. //         SSI0_CC_R   = 0;         // - sysclk for SSI - //
  53. //         SSI0_CPSR_R = 0;
  54. //         SSI0_CPSR_R |= 0x02;     // - CLK prescale divisor - //
  55. //         
  56. //         SSI0_CR0_R = 0;
  57. //         SSI0_CR0_R |= 0x0707;     // - serial clock rate and 8 bit -- //
  58. //                                   
  59. //         SSI0_CR1_R |= 2;          // - SSI peripheral started - //
  60.         
  61.         ///////////////////////
  62.         
  63.         // -- SPI initialisation done -- //
  64.         
  65.         while(1){
  66.             SSI0_DR_R = 0x0008;
  67.             //GPIO_PORTA_DATA_R |= 0x08;
  68.             //GPIO_PORTA_DATA_R &= 0xF7;
  69.             for(countTest = 0;countTest <= 62000;countTest++);
  70.             for(countTest = 0;countTest <= 62000;countTest++);
  71.             for(countTest = 0;countTest <= 62000;countTest++);
  72.             //GPIO_PORTA_DATA_R |= 0x08;
  73.             for(countTest = 0;countTest <= 62000;countTest++);
  74.             for(countTest = 0;countTest <= 62000;countTest++);
  75.             for(countTest = 0;countTest <= 62000;countTest++);
  76.             
  77.         }
  78.             

There are no errors and it compiles. But there is no activity on any of the SPI lines. Now, the Fss pin is the SS(slave select). So after the SSI is enabled, should I actually toggle this Fss pin ? Is this action needed for the data to be latched onto the MOSI pin and then transmitted ?

  • vinod karuvat3 said:
    I am trying to initialize the SSI peripheral by writing my own drivers.

    Most always - such (unjustified) "write one's own" attempts end in failure - just as has yours, here.    

    Vendor has (long) declared his proper "disinterest" in the read/review/analysis of "most all" such "DRM or ASM" code - due to the extra time/effort such code styles demand AND the ready presence of a, "Long Tried, True, Exhaustively User Tested & Extensive API."    With vendor support (so unlikely) - you are left to "outsiders" - and there proves little (i.e. NO) motivation for assisting when (zero explanation/justification) for the desire to, "Write one's own" appears w/in such post.    (we've no wish to, "Do homework or Do another's work assignment" - should either prove the case.)

    If "bound & determined" to (only) write your own - rather than starting from a, "clean sheet" would it not prove immensely helpful to employ the vendor's API example - and then "Step thru the code - noting: Resisters in play, key bit selections/settings, and the code's sequencing?"     Armed w/such data - would you not be so much "better armed" to, "Write your (almost) own" - but this time - with far greater, "odds of success?"

    It must be noted that such APIs exist for very good reason.       In stark contrast - those vastly slower, far more effort laden, untested/questionable "Write one's own" - "Not so much!"

  • Hello vinod,

    We have fully written SSI drivers which have been thoroughly tested and handle all of this for you in our TivaWare software package. Please leverage these for your application. There are examples included as well to help get you running quickly.

    Download link for TivaWare: www.ti.com/tool/sw-tm4c

    As cb1 stated, we aren't going to support custom made drivers using register level calls when the time/effort we invested in TivaWare allow you to achieve the same objective. I would urge you to leverage the time and work we already spent on all our customers behalf to make these drivers rather than trying to re-invent the wheel.