9S12 SPI interface to MAX3100

[KH_SRNL]

I am attempting to interface a MC9S12C128 controller (packaged on the CHIPS12 platform, by ElMicro) to a Maxim MAX3100 UART.  It appears I am having timing issues with the MOSI and SCLK.

The 9S12 is the master, Mode 0, and the Maxim is the slave.  The 9S12 is configured with automatic slave select.  The SPI registers are configured as follows (16 Mhz oscillator on the 9S12)

SPIBR = 0x70

SPICR1 = 0xda

SPICR2 = 0x10

I am monitoring the SPI bus with a Lineeye protocol analyzer, a Total Phase SPI bus monitor (Beagle module), and an oscilloscope (monitoring all four lines).  The data bits are sent by the 9S12, but neither the data analyzers nor the Max3100 correctly receives the data.  The following two commands are sent:

0xc0, 0x2b (Write Maxim config reg)

0x40, 0x00 (read Maxim config reg).

The data analyzers report data, but the bits are incorrect.  The oscilloscope shows the correct bit patterns sent, but the MOSI bits (transmitted) transition with the leading edge of the clock.  According to the Maxim data sheet (and Maxim tech support verified) the MOSI bits must be set before the leading edge of the clock transitions. 

I utilized a Total Phase SPI Master Mode development module (the Cheetah) and configured it as the master to the Maxim chip.  With the Cheetah module, I can correctly transmit data.  The scope shows the Cheetah module setting the MOSI bits before the leading clock edge.

I have successfully used the 9S12 SPI bus in the past, but in the prior application another 9S12 served as the slave module.  The SPI ISR routines are the same for both the current and prior application.  Anyone had similar experiences with the Maxim 3100?  Any suggestions on how to correct the issue?

Thanks

[allawtterb]

I have used the MAX3100 before, not with a Freescale part but a TI MSC1212.  I didn't have any particular problems using them (5 on 1 board) and it sounds like you were able to communicate using your SPI debug tool. 

---

KH@SRNL wrote:

SPICR1 = 0xda

You are setting it to CPHA mode 0 which should be correct but setting CPOL to active-low, which is not correct.  With this setting the rising edge of SCLK would occur with the transition period of of the MOSI and MISO pins which is what you might be seeing with the scope.  Try with a SCICR1 value of 0xD2.  

Message Edited by allawtterb on 2008-05-01 02:32 PM

[KH_SRNL]

Thanks for the suggestion.  What you describe is exactly what I'm seeing (MOSI pin transitions with the leading edge of the clock).  I used 0xD2 for the SCICR1 as you suggested.  It didn't appear to change anything on the output as far as the relation of MOSI and SCLK transitions.

I'll recheck to ensure I didn't do something stupid (like load the wrong program), but it appears that the code accepted the change and loaded correctly.  Any other suggestions?

Thanks

[allawtterb]

---

KH@SRNL wrote:

Thanks for the suggestion.  What you describe is exactly what I'm seeing (MOSI pin transitions with the leading edge of the clock).  I used 0xD2 for the SCICR1 as you suggested.  It didn't appear to change anything on the output as far as the relation of MOSI and SCLK transitions.

I'll recheck to ensure I didn't do something stupid (like load the wrong program), but it appears that the code accepted the change and loaded correctly.  Any other suggestions?

Thanks

---

If you are still having problems with the MOSI not looking correct with respect to the clock I would suggest playing with the clock speed, perhaps try some slower rates.  Also, if CPOL was changed correctly it should idle low, whereas before it should have been idling high.

[KH_SRNL]

Thanks to all for the suggestions, but it doesn't appear that I'm any closer to a solution...  I verified with the scope that the slave select line goes low and stays low for the duration of the 16 bit transfer.  I'm using an interrupt service routine to transmit data, if that matters.

I've tried adjusting the clock speed, it doesn't appear to make a difference.  The current clock period is 60 usec.

The CPOL bit changes the clock polarity (setting it to one starts the data cycle with a high clock line).  The CPHA bit doesn't appear to change the output waveform at all.  Correct me if I'm wrong, but this bit appears to deal with the way the 9S12 samples MISO data.  I reviewed the SPI block guide to see if there's another bit that influences CPHA, but I can't find one.

I disabled the slave select output feature (setting SSOE to zero and MODFEN to zero).  It didn't appear to make a difference in regards to the timing of the waveform. 

Please keep posting suggestions as I'm really stuck on this one and need your help.

[allawtterb]

---

KH@SRNL wrote:

The CPHA bit doesn't appear to change the output waveform at all.  Correct me if I'm wrong, but this bit appears to deal with the way the 9S12 samples MISO data.  I reviewed the SPI block guide to see if there's another bit that influences CPHA, but I can't find one.

It should change the way it samples the data on the MISO (if it is set as a master) and how it outputs data onto the MOSI.  The output should be changing when you change the CPHA, that is the relation between the clock and the MOSI should change when you change CPHA, MISO will not change since it is being controlled by the MAX3100.   Do you see anything on the MISO line? Does it look ok?  You could do bit-banged SPI but I would only do this as a last resort.   

[KH_SRNL]

Thanks to all,  it was a VERY careless mistake on my part.  I initialized the registers at the beginning of the program.  Later in the program I reset the SPICR1 register when I turned on the transmit interrupt.  Using poor coding practice, I hardwired the register and reset the clock phase bit when turning on the transmit interrupt. 

Everything is all good now. 

Thanks to all

[KH_SRNL]

Let me eat crow one more time.  The SS line does indeed go high after the first 8 bits (as was posted earlier by BigMac).  I don't know how I missed it, but I did.  Thanks BigMac, when the transmissions didn't quite look right, it was the first place I looked.

[bigmac]

Hello,

My interpretation of the Maxim datasheet is that the device requires CPHA = 0, CPOL = 0, for correct operation.

I think that the main cause of your problem is that you are using automatic slave select.  This will set SS low for the send of each SPI byte, and raise SS between bytes.  However, the Maxim device would appear to require that SS remain low for each 16-bit transaction.  This will require that the SS pin be controlled by firmware.

Regards,

Mac