SPI speed lower than expected

It's always useful/helpful when posters' provide the datasheet for their "special," problemmatic component.  Also - single board (or single chip) anomalies are always a possibility - much time is wasted if such proves the case.  Have you tried via a 2nd MCU and a second (problem) accessory chip?  Universal problems are more compelling - single board/chip issues - not so much...

From your description it would appear that the errant chip may have some sensitivity to the signals, order and/or data-flow - as initiated by your faster MCU. 

You note that the fastest SPI you can transact at - when targeting the slow chip - is 300KHz.  We're not told just how you reached that conclusion.   Do error rates increase substantially when you exceed that rate?  Or - does the SPI communication completely fail & break down?  Does the failure impact both SPI TX & RX - and equally?  Does the MCU SPI clock cease - or does the data cease or distort - or does the slave simply fail to respond?  Again - we're not provided this (likely) helpful detail...

It's good that you switched the SPI connections - and reported the consistency of findings.

I2C slave devices have the ability to, "throttle down" an I2C master - don't believe that capability extends to SPI. 

I've only vague familiarity w/your new MCU - perhaps the management of the SPI_CS signal requires special care/handling?  It's important that you seriously compare the SPI timing chart between old/new MCUs - trying to discover if any differences exist.  Scope data would provide critical insight - as you must know.

Might it be that your software expects to "read" a certain response from the slave - and should that response be somewhat "off" - the "challenge-response" process repeats - thus appearing to slow your data rate.  Again - we don't really know if your SPI clock has slowed - or if the effective data rate (across multiple data bytes) has been reduced.  Both are possibilities - are they not?

A long-shot - but we have seen it - is for the MCU and slave to be powered up with slight time offsets.  As a result - the receive side of one (or both) may be somewhat disordered - and may cause your effect.

Multiple areas for you to consider here - you should insure that QSSI mode is off (I assume that MCU feature exists) as your SPI devices appear to be single bit. (i.e. standard/old SPI style)

Devil lingers in the detail - not enough facts here (my sense) to identify an exact cause and cure...

I understand my question might be quite stupid and I don't want to have people investigate a specific case for me, but rather ask if this is some common known thing or something more specific.

The chip that's running slower is this one: http://www.vlsi.fi/fileadmin/datasheets/vs1063ds.pdf and unfortunately I don't have multiple copies for it or the mcu to test.

If it's not a normal thing, then I'll just digg into the datasheets and the code to try to find it.

Thanks

Glad that you've provided the chip info - yet all other issues I presented remain silent.  Detail is normal - never stupid - your switch to other SPI ports/connections removes you from any such characterization.

As stated - I've no specific knowledge that MCU nor slave.  I try to present my best sense of issue and cure - gleaned from many years in the MCU trenches...  (and sometimes - get lucky/succeed)

Sorry, for some reason I didn't see your whole post initially.

When I up the SPI speed, it looks like all SPI communication stops, not just increases errors. However I'm not 100% sure about this, I'm waiting for a logic analizer to arrive in a couple of days and will be able to see what exactly happens.

For now I can just see that the vs1063 chip does not read and write spi registers, so I assummed communication totally fails...

And I don't have i2c devices, just the other 2 SPI chips, but for the testing I switched them off.

One interesting thing is that the SPI code for the other 2 chips I took from the tivaware examples - that were done specifically for that mcu, and for the problematic chip - I wrote it myself, which could be the reason. At first glance I don't see anything different in the spi implementations, but I'll do some more digging.

And I'll try your other suggestions tomorrow (it's a bit late here) and will update, in the worst case I may have to wait a couple of days for the logic analizer to arrive to get more details.

Many thanks for the detailed post.

Ahh thanks, that solved it.

The SysCtlClockSet function was not used, so clock was properly set, but that application note shows that SysCtlClockGet is also missing and I used that to do the spi delays.

So in my case it always reports some weird 9600000 value, instead of the correct frequency, which explains why changing the mcu speed affected the spi.

In the tivaware examples the frequency is taken like that

g_ui32SysClock = MAP_SysCtlClockFreqSet(...)

and that global var is used instead of calling SysCtlClockGet() (like it was with tm4c123), but I thought that was just to save some calls :)

So I removed those calls and used the global var and it's working on the full speed now.

Many thanks both for the help!