MCF51CN128 Reference Manual (rev 6) - SPI slave operation when CPHA = 0 is not adequately described

[armistej]

In the SPI functional description, it mentions that when CPHA = 0 in the SPIxC1 register, that only a single transfer can take place when the SPI is in slave mode for each time  /SSx goes low (refer section 14.5.1).

But, what is not explained, and what we grappled with for several hours, is the fact that you CANNOT load new data into SPIxD when /SSx is low if you are in slave mode and CPHA = 0.  At least, this is what we determined for SPI port 1.

If we loaded SPI1D on power-up with data (say, 0xAA), then the first time the master transfered a byte to us, we'd shift the 0xAA byte back to it.  So far, seemingly so good.

But, if when we got the interrupt for SPI receiver full (SPI1S bit SPRF set), and in the ISR we tried to put another data byte (say, 0x55) into the SPI1D (to transmit it), it would NEVER appear on the SPI bus back to the master, even after /SS1 had gone inactive and then active again for the next transfer.  We would NEVER see the 0x55 byte.  It was as if it was being thrown out of SPI1D, although looking at the object code and single-stepping in the debugger showed it was being put there.

Any ideas ?

At the very least, I'd hope Freescale could document this behavior a bit more clearly in the Reference Manual !

Regards

J

[WHookway]

Hi,

I am using the MCF51JM128 and I am experiencing a similar problem.  My situation may be different in that I'm using MQX and the SPI lib (may write my own, since it does not take advantage of MQX), but I am very interested in this answer.  I wish to transfer a block of say 50 bytes in a single transfer and I am only receiving the first byte at the master.  Each subsequent 50 byte transfer request from the master returns the next byte that I loaded into the transmit buffer on the MCF51 side.  The remaining bytes after the first are all zero.  The reason I mention this is I compared you manual to the 51Jm128 and the description of the clock is very similar.  It sounds as if you are equating a single transfer to a single byte (for each CS), I see no restriction such as this.  Are you thinking that a transfer is limited to 8 bits for each CS, this would be a disaster for me.  Is this what this timing diagram really implies?

Thanks,

Will

[WHookway]

Hi,

After further reading I think you have identified my problem.  I missed this difference in the operation as it relates to the edge the data is clocked / sampled on and the relationship to the slave CS input.  I was using CPHA = 0 , this sounds as if it is my problem.  I will switch to CPHA=1 and give it a try.  (My hardware is being upgraded for another issue, so I'll be able to test late today or tomorrow.)

Regards,

Will