Weird SPI Behaviour

[MJB]

I currently have two MC9S12NE64s, one acting as a master and the other a slave. The master is transmitting nicely. As a test I have it cycle and transmit between 0 and 255. On the recieving end I notice some weird results! It gets the data, but depending on when it is reset and initialized it sometimes has the bits arranged incorrectly.

For clarification SPI master is sending 0x01, 0x02, 0x03, etc.
SPI Slave sometimes receives correct data, sometimes it gets 0x02, 0x04,0x06 or 0x04,0x08,0x0C or 0x08,0x10,0x18 and so on.

Sometimes its shift orientation is off from what it should be!

I'm using interrupts as to allow the processor to do other things. Also using Codewarrior and demo boards.

I'm completely baffled. Any help would be greatly appreciated!

Thanks

[mortontd]

Are you using the /SS signal on the slave? I had the same problem when I had the /SS tied low. It worked after tying it to an enabled /SS from the Master.

Hope that helps,

Todd Morton

[MJB]

Ya I have my SS tied to the SS of the master and it still does that weird stuff. I tried grounding SS and it shows the same odd behaviour.

[EmbeddedCoder]

Do you have the CPOL and CPHA bits in the SPICR1 Register set to the same values in both Master & Slave device?

This can cause all sorts of wierd interactions!

[MJB]

I did have them equal. But when I did this no receipt took place. Occasional receptions were made but with totally random numbers. I used both bits to be 0. Then I tried CPHA 1 on the master and it magically worked. Then I hit reset and those problems discussed above occured. The same thing occured when I just grounded my slave with CPHA and CPOL equal in both devices.

[MJB]

Sometimes even I am amazed by my own stupidity. I fixed it thanks

[MJB]

I got it to work with CPHA=1 on both NE64s but it flat out refuses to work with both having CPHA=0. The slave never recognizes a transmission and an interrupt never occurs. Anyone have any suggestions comments or advice?

Thanks.

Message Edited by MJB on 04-07-200604:58 PM

[bigmac]

Hello MJB,

For the SPI to work when CPHA = 0, /SS line at the slave must go high again at the end of each byte transfer, and then return low for the next byte.  This is not the case when CPHA = 1, where /SS may remain low.  I suspect that, if you are trying to use /SS as an output at the master, to feed the /SS input at the slave, this may not be set up correctly.  You could alternatively use a general purpose output to drive the slave /SS line.

Regards,
Mac

[MJB]

Can I have CPHA=0 on the slave and not have the requirement of SS going high between byte transmissions? What I have and want to receive is a 32 bit stream which is indicated as valid by a negative active line. So the first positive edge clocks the data in and on the last negative edge the line which indicates whether the data is valid goes high.

Also is there a reason why it won't work in cpha=0 mode even when I put idle times in?

Thanks

Message Edited by MJB on 04-10-200611:51 AM

[bigmac]

Hello MJB,

MJB wrote:
Can I have CPHA=0 on the slave and not have the requirement of SS going high between byte transmissions?

Since your slave end is another MCU, this will require SS going high to receive the byte.  I do not understand why you must have CPHA = 0 since you have control over the setup of both ends of the link.  The principal requirement is that the master and slave must match for both CPHA  and CPOL.

What I have and want to receive is a 32 bit stream which is indicated as valid by a negative active line. So the first positive edge clocks the data in and on the last negative edge the line which indicates whether the data is valid goes high.

To use the SPI, each group of 32 bits must be handled as four separate bytes, with sufficient time between the bytes to allow each received byte to be placed in a buffer, presumably by the SPI receive ISR.  I am not clear about your handshake, and what you mean by a "negative active line" - do you refer to the  SCK line?  If you need to detect whether the received data contains errors, you could always return a suitable acknowledge byte to the other end in response to each 32 bits.

Regards,
Mac

[MJB]

Sorry let me clarify and I really appreciate the help.

I have a seperate outside set of signals, one clock, one data line and one negative active device select line. The negative active device select line goes low at a negative edge of a clock and each positive edge of the clock captures data. This is done for all 32 bits being fed in serially and on the last negative edge the negative active device select line goes high. I was hoping to use an MC9S12NE64 in slave mode to capture this data.

For testing purposes I hooked up two MC9S12NE64s together. One generated signals and one, in slave mode captured. I'm having problems even getting them to work with CPHA=0 connected together. Is my thinking wrong? Can this not be done with the MC9S12NE64 SPI as I first thought?

Thanks for the help.

On a side note, when testing I have both SPIs with CPHA=0 and generate waveforms indentical to the ones in the spec sheets but I cannot get the slave to read. Any ideas?

Message Edited by MJB on 04-10-200602:10 PM

[bigmac]

Hello MJB,

To further clarify the actual data transfer from the external source -

• Does the clock line idle high or low, i.e. is the first clock edge negative or positive?
• Does the MSB state appear at MISO before or after the first negative clock edge?
• Am I correct in assuming that the data changes occur in the vicinity of each negative edge, and are sampled by the slave on each positive edge?

This will help determine what are the correct settings for CPHA and CPOL.

Whether the 32-bit transfer (handled as four bytes) can work or not will also depend on the incoming clock rate, and whether there is enough time to process the previous byte before the first clock edge of the following byte.  So the SPI clock rate must be relatively slow - an indication of the SPI clock rate, and also your bus rate, would be useful.

Regards,
Mac

[MJB]

Hello,

The input transmission is not true SPI I was just hoping to capture it with an SPI slave.

* The clock does not idle. It keeps chuggin along even if data is not to be sent.

* The "SS" pin goes low on a negative clock edge. The first positive clock edge sees data bit 1. The second positive clock edge sees data bit 2.

* Yes each sample should be taken at the positive edge.

* This data is comin in at like 3 mhz

Let me try to explain it it words better:

The clock is always working. When data transmission begins Data valid goes low at the negative edge of the clock. The data also changes to the data needing to be transmitted. The data is sampled on the positive clock edge. This continues up until the 32nd bit where it is sampled on the positive clock edge. On the negative edge the Data valid line goes high.

Thanks for the help.

Here is the waveform

http://img127.imageshack.us/img127/6185/wave2ql.jpg

Message Edited by MJB on 04-12-200610:25 AM

[rocco]

Ah, now I understand. One timing diagram is worth 1024 words!

From the title of the thread, I thought that your SPI was behaving weird, not that you were trying to make it behave weird. :8)

Thoughts:

Since CPHA=0 requires that SS occurs between each byte, you will need to use CPHA=1.

Since you need to sample the data on the rising edge, you need to set CPOL=1.

Your Data-Valid needs to drive SS (as you already have it), but it may not be possible to get the first bit. You stated that SS will go low with the falling edge of the clock, but there is a setup time required by the slave (one Tcyc, I believe) from SS to the first falling edge. So depending on the actual timing between the falling edge of SS and falling edge, it may or may not work.

If SS falls prior to 1 Tcyc before the clock falls, you are in good shape.

If SS falls after the clock falls, you will probably loose the first bit.

If SS falls in between the above two cases, you have violated the setup time for the clock, and the results are unpredictable (at least by me).

[imajeff]

MJB,

First of all, I know the prob is not that it's a NE64 instead of DP256 or such. AFAIK all the 9S12 devices have similar if not same SPI, so many people should have experience which would help.

I am trying to figure out if you are trying to have SPI use SS in order to frame the 32 bits, because it can't do that. You will I guess have to config SS as general-purpose input, then have software note the start of 32 bits.