This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USCI in SPI mode: where is my UCB0CLK?

Other Parts Discussed in Thread: MSP430FR5726

Hi to all!

MC is MSP430FR5726 (FR57xx family)

It has eUSCI_A0 and eUSCI_B0. I use the 1-st of them in UART mode and I want to use the 2-nd in SPI mode.

Problem: there is no clocks at the UCB0CLK pin. 

The relevant info may be summed up so:

1) The USC0CLK pin is checked electrically: being configured as OUTPUT port it may be set to "0" or "1"

2) The eUSCI is configured: when I put a byte in the UCB0TXBUF it is transmitted correctly - but without the clock pulses at the USC0CLK pin (as if it is a UART mode!)

I double checked UCSYNC bit and UCMODE0...1 bits in UCB0CTLW0 register - it looks as sync mode and 3-wire SPI:

   	UCB0CTLW0 |= UCSWRST;	// Disable the USCI during configuration
   	UCB0CTLW0 = (
   		(UCCKPH & 0)			|	// Sync. Mode: Clock Phase = 0
   		(UCCKPL & 0)			|	// Sync. Mode: Clock Polarity = 0
		(UCMSB)					// MSB first
   		(UC7BIT & 0)			|	// 8 bits
   		(UCMST)				|	// Sync. Mode: Master Select = 1
		(UCMODE1 & 0)			|	// Sync. Mode 00: 3-pin SPI
		(UCMODE0 & 0)			|
                (UCSYNC)				|	// Sync. Mode = SPI
		(UCSSEL1)				|	// Clock select: 11 = SMCLK
		(UCSSEL0)
   			);
   	UCB0BRW   = 8; //3686400L / 460800L - 1;

	PIN_AS_OUT_2ND( SPIMOSI_PORT, SPIMOSI_PIN);	// SIMO (MOSI) pin P1.6
//	P2SEL0 &= ~(1<<2);
//	P2SEL1 |=  (1<<2);
	PIN_AS_OUT_2ND( SPICLK_PORT, SPICLK_PIN);	// SCLK  pin P2.2
	PIN_AS_INP_2ND( SPIMISO_PORT, SPIMISO_PIN);	// SOMI (MISO) pin P1.7

	UCB0CTLW0 &= ~UCSWRST;

(Commented is the setting of clock pin without the macros - the result is the same)

Where am I wrong?

Additional info, may be irrelevant: the baudrate is set not according to manual 

f BitClock = f BRCLK /(UCBRx+1)

Instead, the baud rate of series signal at the UCB0SIMO pin behaves as 

f BitClock = f BRCLK /(UCBRx+0)

for all UCBRx > 0. I checked it experimentally with UCB0BRW register...

Regards,

Yura Vlasenko

Ukraine, Kyiv

  • Well, I'm a stupid. 

    My problem was caused by oversetting of UCB0CLK pin somewhere in the program (actually, in my Modbus library, precompiled some time ago). It was configured as a mere output port. Consequently, USCI_B0 could not control this pin.

    By the way, I found my error in such a way: I transmitted the UCSSEL1 and UCSSEL0 registers via the very same UCSI_B0 :) And it showed the real setting of P2.2 pin.

    The "problem" is solved. 

  • There's another 'bug', which may lead to unpredictable behaviour:

    In the code, the first line set SWRST, but the second line doesn’t include SWRST, effectively resetting it. The rest of the initialization is done while the USCI is already operational. Which is bad, especially for setting UCB0BRW.

  • Jens-Michael Gross said:

    There's another 'bug', which may lead to unpredictable behaviour

    Indeed it is! What an unexpected turn of the topic!

    Thank you for this very important information. All that I can add: this unpredictable behaviour may be quite harmless sometimes. The abovementioned program code is used in another init function - eUSCI_A as UART. The same bug, but I was lucky: no visible errors in a year's period (about 20-30 modules).

    Going to eliminate these 2 bugs immediatly, Sir!

  • By the way. One thing is uncleared:

    Iurii Vlasenko said:

    the baudrate is set not according to manual 

    f BitClock = f BRCLK /(UCBRx+1)

    Instead, the baud rate of series signal at the UCB0SIMO pin behaves as 

    f BitClock = f BRCLK /(UCBRx+0)

    for all UCBRx > 0. I checked it experimentally with UCB0BRW register...

    Any ideas?
  • Iurii Vlasenko said:
    this unpredictable behaviour may be quite harmless sometimes


    Maybe this bug has no negative effect if the USCI wasn’t in operation before. Or if UCBRW was 0 before.
    Changing the baudrate divider while the USCI is not in reset, then it may have an unpredictable result on the generated baudrate.

    Iurii Vlasenko said:
    the baudrate is set not according to manual 

     You’re right, the formula in the users guide is wrong. In fact, the formula is fBRCLK/UCBRx, except for UCBRx=0 (which is an invalid divider and is replaced by 1 internally)
    The formula is correct for the UART and I2C chapters of the users guide and also in the FR58xx/FR59xx users guide, but wrong for USCI and eUSCI in F5xx, and the eUSCI SPI chapters in FR57xx and FR2xx/FR4xx users guide.

     Well, since in SPI mode, the master defines the clock speed, maybe nobody has noticed. I made my original SPI code for the 1x family USART, where the formula is correct too. I apparently never re-checked it when migrating the code to the F5x family, so my code worked as expected :)

  • Jens-Michael Gross said:

    You’re right, the formula in the users guide is wrong. In fact, the formula is fBRCLK/UCBRx

    Have we to give a signal to the TI in any way? Or let it be as is? 

  • I’ve added this to the long list of documentation quirks and errors that I maintain. And every now and then I submit it. However, on msot documents, there is a ‘submit documentation feedback’ link on every page. Go and get the merits :)

  • Jens-Michael Gross said:

    ‘submit documentation feedback’ link on every page. Go and get the merits :)

    Done. 
    Never looked at these links... Thank you!
    Regards,
    Yura
  • I've had that issue some time ago, I think:

    http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/359230.aspx

  • Yes Sir!

    It is the very same problem. Well, it will be corrected someday. 

**Attention** This is a public forum