MSP430F5438A: Master always receiving high on SOMI pin

Hello Rahul_Chavan,

Do you have a way to monitor the SOMI pin to see the actual data on that pin? (oscilloscope, logic probe, etc?)
What happens if you don't use the 8051 slave and just short the SOMI and SIMO pins together?

Looking at the port pin schematics,direction is controlled by P3DIR.x, but the table tells that P3Dir is a don't care if P3SEL.x is set. Which is correct, as far as I remember from own projects.

P3IN.x should always reflect the physical state of the pin. The signal to P3IN is not switched by P3DIR or P3SEL. At least that's what the pins chematics say.

You use UCA0STE pin as chip select for the slave. However, "UCA0STE" only makes sense as input, as it switches the amster into slave mode. For slave vhip select, you can use any pin you like form any port you like. it is a simple, user-controlled logic signal. Using the name UCA0STE is misleading. You can use any number of CS signlas for the same SPI interface to address any numberof slaves through the same MOSI and SIMO lines.

So better define a signal CS (or maybe SLAVE1_CS) and use this.

As long as CS is high, the slave remains neutral. When CS goes low, the slave may or may not drive SOMI low (or high) depending on its SPI mode and the first bit it woudl transfer.

IIRC, the TI polarity is the opposite of the motorola polarity. So you need to set CKPL for an 'inactive high' clock.

Besindes a possible mode mismacht with CKPL=0, the configuration seems to be correct.

But if after this config you just check UCA0RXBUF, it is no wonder that it shows 0xff. TO receive anything, clock pulses must be created. And clock pulses are created by sending something.

If oyu write a byte to UCATXBUF, 8 bit are sent to the slave. And with each bit you send, a bit is received into RXBUF. Howevr, the bis received are sent by the slave while the slave hasn't yet received your byte. And therefore cnanot echo it (unless it is configured on hardware level to mirror the MOSI signal  to MISO pin like a wire bridge would do. You can achieve this internally to the USCI by setting the UCA0STAT.UCLISTEN bit.

Normally, (with programmed I/O), when you sent the first byte, the slave has received it while you received something invlaid (whatever the slave meant to send you before it knew what you are sending him). When you send the next byte (check for TXIFG bit for a seamless buffered send or for UCA0STAT.UCBUSY if you want the first byte transfer being ended before you start the next) then you will receive the return value for the first byte for the slave while you are sending the second.

The two things to remember with SPI are:

NO SEND, NO RECEIVE and

YOU GET YOUR ANSWER WITH THE NEXT TRANSMIT

well, and don't set CS high too soon. Wait for UCBUSY, so the slave has received the last bit before you de-select it. Else the transfer is canceled and the slave won't ever receive the complete byte.Even though TXIFG was set long ago, indicating that TXBUF is empty. Yes, TXBUF is empty and ready for the next byte, but the shift register is still busy sending the last byte. The double-buffering behavior can easily lead to confusion. But it maximizes throughput as you can always have the next byte already waiting in TXBUF where the output register can fetch it without delay for seamless transmission.

There are lots of threads i this forum about SPI and USCI. Search them for additional info.

Hi Dennis,
Thank you for replying.

I am viewing the signals from SOMI & SIMO on an oscilloscope.
I tried shorting SOMI and SIMO pins bypassing 8051 slave, got the same signal pattern on both pins.

Hi sir,

Thank you for replying.

Here are my observations (PS: Viewing all observations on an Oscilloscope & in Debug mode registers.)

Jens-Michael Gross said:

P3IN.x should always reflect the physical state of the pin. The signal to P3IN is not switched by P3DIR or P3SEL. At least that's what the pins chematics say.

Checked P3IN in debug mode, and it is correct. Still, I will put one line before P3SEL to set the P3IN register.

Jens-Michael Gross said:

You use UCA0STE pin as chip select for the slave. However, "UCA0STE" only makes sense as input, as it switches the amster into slave mode. For slave vhip select, you can use any pin you like form any port you like. it is a simple, user-controlled logic signal. Using the name UCA0STE is misleading. You can use any number of CS signlas for the same SPI interface to address any numberof slaves through the same MOSI and SIMO lines.

Tried shorting the UCA0STE pin to ground. Still got the same result, that is high SOMI signal.

Jens-Michael Gross said:

IIRC, the TI polarity is the opposite of the motorola polarity. So you need to set CKPL for an 'inactive high' clock.

I will set the CKPL for an 'inactive high' clock.

Jens-Michael Gross said:

But if after this config you just check UCA0RXBUF, it is no wonder that it shows 0xff. TO receive anything, clock pulses must be created. And clock pulses are created by sending something.

Created a clock pulse of 4MHz on SMCLK and using it in code, still, the result is same.

Jens-Michael Gross said:

NO SEND, NO RECEIVE and

YOU GET YOUR ANSWER WITH THE NEXT TRANSMIT

Yes. Actually the same code was working previously, and I was getting the signal as you said. but I just changed the Clock frequency from 4MHz to 25MHz to see the changes but in return, I got a Sinusoidal signal from slave on SOMI pin. So I changed the clock frequency to 4MHz again but from then I started getting High 0xff signal from Slave.

Tried different methods like changing the delay between Bytes I am sending, Changing the clock frequency from 1MHz to 25MHz again, Setting the P3REN to pull down the SOMI pin voltage. But still the result is same.

Besides this, if you think I should do something more, then please help me.

"Tried shorting the UCA0STE pin to ground. Still got the same result, that is high SOMI signal."

UCA0STE (or, more exactly, CS) has no impact on the master. It is just a signal to the slave to react or ignore the SPI bus.
The UCA0STE signal, if configured mit P3SEL for module use, is a plain input signal to the USCI and only used in 4-wire SPI mode. It switches the USCI from master into slave mode (independently of UCMST bit) for multi-master configurations. In 3-wire mode, it isn't used. So you shouldn't use this symbol when you use the pin as slave chip select.

BTW: in your code, you already defined UCA0SOMI. So why don't you use it for setting P3DIR and P3SEL? :) It makes the code more readable and reducxes chances of misconfiguration.

Yes. Actually the same code was working previously, and I was getting the signal as you said. but I just changed the Clock frequency from 4MHz to 25MHz to see the changes but in return, I got a Sinusoidal signal from slave on SOMI pin. So I changed the clock frequency to 4MHz again but from then I started getting High 0xff signal from Slave.

It's strange but it sounds as if the high frequency has damaged the slave. I don't know why and how this could happen.
AFAIK, only the 89S series has a built-in SPI interface, the original 8051 and the 89C derivates don't. Now the 89S has 4V minimum supply voltage and therefore at least 4V I/O output voltage too, whiel the MSP supply voltage is 3,6V at most. The MSPs clamp diodes may damage the slave's output drivers. High frequency may increase the problem due to capacitative issues.
Also, the AT98S53 data sheet tells "1.5-MHz Bit Frequency (max.)" for the UART SPI mode. (which is quite slow). It doesn't tell whether this is a limitation of master mode or also applies for slave mode. The Atmel data sheets are incredibly unstructured and incomplete. But the timings for the SPI in programming mode indicate a 2MHz limit (fOSC/12) too.
Now I don't know what exact device you have; this was for the AT89S53. There are so many 8051 derivates out there from different manufacturers...

Hi Rahul_Chavan,

Let me make sure I understand, now that I see your additional information - you had the SPI working @4MHz? Is this the is MSP430 MCLK frequency or the actual clock frequency on the SPI_CLK pin?

If this is the SPI_CLK frequency, and you increased to higher frequency, it is very possible you have exceeded the input clock frequency of the 8051 SPI peripheral.

If instead this is the MSP430 MCLK frequency you are referring to, what is the actual SPI_CLK frequency when it works and when it doesn't work. Please measure with oscilloscope or logic probe to confirm. thanks :)