SSI configuration for LM4F232H5QD

You are aware that numerous examples of SSI set-up/config appear w/in the "tried/true/extensively tested" StellarisWare.

None w/direct register writes - as you've chosen.

Hard to fathom benefits gained from, "sailing into the wind."  (especially as this is set-up code - executed just once)

While I definitely agree with cb1_mobile that code written using the DriverLib APIs is many times more maintainable and understandable, I realize that I'm coming at this from a software perspective and that it's down to a matter of taste and that some people prefer direct register access. Looking through this code (with a datasheet open and DriverLib source and headers for cross-referencing purposes), a few things stand out:

1. How is your system clock configured? Is the PIOSC enabled? If not, your SSI won't run as expected.
2. I don't see any write to the GPIO_PORTD_DEN register. This is needed to enable the digital pins. You may also like to look at the implementation of GPIOPadConfigSet and GPIODirMoreSet in driverlib/gpio.c to see if there are any other registers you need to write. I suspect the reset defaults for those registers are probably OK but it wouldn't be a bad idea to check.
3. You seem to be turning internal loopback mode on (SSI_CR1_LBM). I suspect you don't want to do this since this is something typically used in test and debug rather than normal operation.

You say you are not getting "appropriate" signals on CLK and FSS. Does this mean you are not seeing these pins wiggling at all or that they are wiggling but not in the way you would expect for the chosen mode? If they are not wiggling, I'm pretty sure the problem will be somewhere in the pin configuration. If they are wiggling but in an incorrect way, that would point to an SSI configuration error and you should be able to determine what's wrong by examining the code in the SSIConfigSetExpClk function in driverlib/ssi.c.

We should further note that - beyond matters of "taste" - the long "tried/true/tested" StellarisWare functions provide key "guardbands" (i.e. asserts) which do much to insure that user's objectives are accurately met.

Indeed - as Dave states - multiple data sheet(s) must be very open - and scrutinized - as even a single mis-set bit - in one register - may wreak havoc!

For most any application - the far greater effort, attention to detail, and lack of any/all "safeguards" - makes direct register a far more error-prone, risky choice.

There are occasions where code execution speed and size restriction matter - however the set-up/config of a complex peripheral hardly qualifies...

And - by utilizing StellarisWare from the outset - the pertinent StellarisWare functions may easily be reviewed.  These provide great insight into the registers employed - key bit handling - and may serve as an excellent "model" for subsequent migration to direct register (or beyond) as and if needed...  Starting w/the more complex direct register method may not best satisfy risk-effort-reward...  Poster's failed attempt - so often repeated - appears inefficent & misguided...

Hi Dave,

Thank you for your valuable suggestion.

In fact I am not at all getting signals at SSICLK and SSIFSS as I was measuring these signals in the scope.

I ll implement your suggestion and look forward for positive results

Thank you.

Oh well...

Sailing 101, "Do NOT Sail directly into the wind!"  (must "tack" 45° off wind direction)

US Army Field Manual (Mines), "Do NOT walk directly into a mine field!"

Yet - (somewhere) one hears, - "Damn EASE/EFFICIENCY/SAFEGUARDS (all over-rated) - Full Speed ahead!"