1st: SSI baudrate setting when act as a slave; 2nd: How does SSI receive a 32 bit long word, as a slave

 3 days, nobody know?? Close e2e!!

Feel your pain - while I've no direct experience w/SSI in Slave Mode - have what I believe to be safe, logical suggestion.  Trial/Error often "unlocks" such mysteries...

Indeed the master sets the clock - but might your, "pre-load" of your Slave's clock - to match as closely as possible your known Master clock - make sense?  As an alternative when only "best guess" will do - suggest you set it to "middle of the road."  Several test transmissions - and resultant Slave (your MCU) data capture/review - should resolve whether such setting is indeed non-sensical.

As for interrupt - believe several "reads" of the MCU data manual may assist.  That said - your SSI, Slave Interrupt routine may fire a GPIO - with scope monitoring the SSI clock and that "firing GPIO" - the occurrence (time-line) of the interrupt may be thus determined..

Thank you cb1!

For the baudrate setting in slave mode, I can only guess it is something like "sample rate" or "close to the master clock rate", but it is only GUESS. so I raised it in e2e. Your suggestion is same as the 2nd guess. But why do I have to guess geuss and guess? it is matter of 1+1=2 .

For the interrupt, I will try your method. It is a good suggestion. Thank you.

You are most welcome - my friend.  Consider this - you "know" your Master SPI clock rate - that's a given.  Thus - "matching" your MCU Slave to this Master clock may indeed make sense.  

In the case where the Master clock is truly "unknown" - you can "set" your Slave clock rate - and direct your unknown Master to, "best match it."  Of course - as you note - guess reigns supreme here - but some slight logic is along for the ride...   Good luck - let us know if this succeeds...

One final point dawns - which I believe may assist - when further/different MCU issues arise.  While each ARM vendor individually implements their "mix" of peripherals - quite often we've found "reasonable" consistency.  I do not suggest "exact" correlation - but more often than not - similarities are noted.  Thus - should future forum requests languish - other investigation paths may resolve/comfort...

Would be appreciated if you, "Close the Loop" on this Slave MCU - SSI Clock and Interrupt operation.  This usually insures faster (and better) response to your future posts.  Wish you well...

I am not sure I understand well. I investigated Atmel ARM9 spec - AT91SAM9M10. In SPI chapter I can find one statement that is " The baud rate
generator is activated only in Master Mode ". The below diagram can understand SPI clock easily.  This is what I want. I will try setting next Monday, will back to you with the result.

 .

A rather original choice - perhaps a look/review of other M4 devices makes sense too...

Junchuan,

One thing i don't understand: although not forbidden, why do you read data sheet of an ARM9 microcontroller and don't read the user's manual of your M4 microcontroller? In  my LM4F232H5QD manual I can read this:

When the SSI is configured as a slave, it disables the SSIClk pad     

on page 973, paragraph 15.3.4.6. Also important info related to timeout and interrupts are presented into chapter 15- SSI. Can you read (and understand) this first?

Petrei 

Petrei said:

From 232 UM: When the SSI is configured as a slave, it disables the SSIClk pad

Perhaps because - statement as written - is rubbish!   SSIClk may indeed be disabled as output - but one rarely (never) encounters an asynchronous SSI port!  Thus - poster's quandry seems valid...

I've not made time/effort to review such MCU's Slave Mode - suggested that, "preponderance of evidence" from other (M4) devices may provide comfort.  (agree that ARM9 choice by poster was, "curious.") 

In retrospect - suggest that visit to "official" ARM site (maker agnostic) - and search for SSI write-ups there - would be superior, "first search."

@cb1-

Yes, you are right, SSI port should be synchronous - I have checked on ARM site - their SSI module description speaks about SSIClkOut pad, while being another SSIClkIn pad. I suppose both goes to the same pin - anyway I think the TI's user manual must be corrected. 

Petrei 

Petrei said:

user manual must be corrected.

One would hope!  (devil SO lurking in such detail) 

As long past "tech writer" - producing even several hundred page doc. is an ordeal.  1400+ pg. is, "off hook!"  And - guys/gals w/ such skils/understanding "usually" are not especially fond of writing/explaining for "we feebs..." 

And - as they are SO close to the material - their awareness of what those "less skilled" - realistically need/require often is dulled... 

In "ideal world" - a "reviewer" w/ skill set best matching the prospective client/user - would perform page by page review.  (I knew this to be done in U.S. space program - today in many medical device firms - but "not so much" in our MCU field...)

Final thought - all such manuals are produced under threat/pressure of "deadline."  No such threat/pressure impacts we "out-siders" - poster's "find" was first mention of this flaw - iirc...

Petrei

Let me tell you Engineer story: most of us are facing many projects in same time - with deadline. we are using several brands of MCU. Although we are busy, we have to read UM or DS firstly - not like you image. But can you understand if you get lost in these technical docs you are becoming crazy!  Look at my question above, as a result of presure of deadline we worked on Sunday, can you believe it that we set the baudrate as none-zero value, it always works! -- even it is 1. It 'die's only when it is 0. The second result is we feel that when we set a faster baudrate, SSI will 'response' faster a little bit.

Believe me, nobody have time to 'walk round' here. what we want is to finish the job asap and then we will have time to enjoy sunshine(maybe another new job...).

cb:

the status is - we can send data through ssi. but when receive we always get 0. we will check it carefully.

the interrupt happens alway when there are 4 level buffers in FIFO, in the other word, each time we can read out 4 data.

by the end, thank you for your help. M4 is really a great chip !  So powerful !

Your set-up & execution - unknown to us.  Recall that SSI transmits and receives, "at the same time" (often on different clock edges).  Thus - if your SSI Master has been properly (or automatically) set-up/configured to send data to your MCU Slave (and your Master & Slave Address match) and your MCU Slave has been properly set-up/configured - seems that your MCU Slave "reception" should be reasonably, "automatic." 

We know that you have a 32 bit transfer requirement.  Suggest that - for beginning test purposes - you reduce this to 8 bit transfers - to increase your odds of success.

You say that you can, "Send data through SSI" - but unknown is if this is w/MCU configured as Master or Slave. 

Kindly describe what you are using as SSI Master - which is attempting to "talk" to M4, MCU Slave.  Now would be a good time to scope the MOSI and SSI_Clk pins - to confirm that your Master indeed is transmitting.  Have you properly connected the Master and Slave SSI_CS?  Is the level "sense" of both Master & Slave SSI_CS matched?  (i.e. if one seeks "high" - and the other "low" - you must impose an inverter) 

IIRC - in M3 case there may have been some, "special treatment" of SSI_CS - when employed as Slave.  (as you are attempting)  If this is your case - re-read of MCU data manual should clarify.  Like you - we work w/multiple ARM MCUs - from multiple vendors - hard to keep them all straight.

Believe your first order of business is: a) confiming treatment of SSI_CS at Slave MCU.  then b) confirming that Master is transmitting 8 (not 32 bit) data to the Slave and only then observing the MCU's Slave SSI Data Register for data's presence.

LM4F110B2QR ---- always acts as slave in my project.

Yes, we set the Master(DSP) to send 16 bit data format. Level are matched. They are all 3.3V.

In ISR, we put 1 16-bit data into ssi transmit FIFO each time after we get 1 data from receive FIFO. Every bit is shifted out on one clock. we can see all waveform - Fss/clk/Rx/Tx - all are correct. 

We don't have address for M4.

Re: Address - sorry - lost my mind (drifted back to I2C project for a client). 

By matching - I meant to make certain that Fss of both your MCU Slave (M4) and the MCU Master (DSP) agree.  I seem to recall some restriction on the Fss input - when the M4 MCU is configured as Slave.  As you see SSI data & SSI clock via scope - something is misconfigured w/in M4 Slave set-up - for you to receive only data 0x0.

Recall that in Master SSI Mode - you have multiple "set-ups" for the M4.  (Freescale, TI etc.)  Perhaps you're not well matched here?

I now recall reading that SSI Slave runs substantially "slower" than SSI Master.  (as regards M4 & M3)  (from memory - seem to recall 8 times slower - when in Slave Mode)  Can you "slow" your DSP Master - to better accommodate this reduced clock rate for MCU Slave?  (I'm about out of diagnostic tricks - should this not work...)

Finally we solve the problem!! 

The answer is:

The Rx pin is protected by MCU, since it is a multi-purpose pin which named NMI as well.

To alternate NMI pin to Rx, you MUST unlock it before you use it !!!!!!  What a simple mistake!!! You can not say it is TI fault. Because IT tells you about this in other chapter. But they are not connected. So TI said Hey guy! Read our datasheet carefully, or you will waste your time. I said YES sir!

Thank you cb for your kindly help! 

Seems I was right asking you to read the right manual...

Petrei 

Glad you persisted - and solved issue.

There are only 2 such "NMI" pins on M4 - bad luck that SSI Port you choose was so burdened.

For those interested - was any setting of SSI clock speed accepted?  Did you attempt to optimize?  Is clock speed reduced when MCU acts as SSI Slave?

hi cb

I will do some optimization later. Now we are being busy on catching up schedule. Will let you know the result later.

Petrei,

why not TI put some warning in some special chapter? for example, TI can warn user in SSI chapter that when using SSI1 port, care should be taken NMI conflicts with Rx pin. You know there are not too much pins like this. Only 5 pins.