• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 80 subscribers
  • Views 395 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

MSP430FR5962: MSP430 cannot receive correct data

MSP430FR5962: After changing the SPI communication mode, the two chips cannot communicate normally

xi.yan.kiana
Intellectual 440 points
Part Number: MSP430FR5962
Other Parts Discussed in Thread: MSP432E401Y

Tool/software:

Hi teams:

    I use TM4C1290 and MSP430 chips for SPI communication. TM4C is the host and MSP430 is the slave. The original configuration is mode 0, clock polarity is 0, phase is 0. Now the communication mode of the two chips is changed to clock polarity is 0, phase is 1, but the two chips cannot communicate normally.

MSP430 related definitions:

#define UCCKPH (0x8000) /* Clock phase select */
#define UCCKPH_H (0x0080)
#define UCCKPH_0 (0x0000) /* Data is changed on the first UCLK edge and captured on the
following edge. */
#define UCCKPH_1 (0x8000) /* Data is captured on the first UCLK edge and changed on the
following edge. */

TM4C related definitions:

#define SSI_FRF_MOTO_MODE_0 0x00000000 // Moto fmt, polarity 0, phase 0
#define SSI_FRF_MOTO_MODE_1 0x00000002 // Moto fmt, polarity 0, phase 1
#define SSI_FRF_MOTO_MODE_2 0x00000001 // Moto fmt, polarity 1, phase 0
#define SSI_FRF_MOTO_MODE_3 0x00000003 // Moto fmt, polarity 1, phase 1

//Before:
//Master:
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    
GPIOPinConfigure(GPIO_PB5_SSI1CLK);
GPIOPinConfigure(GPIO_PB4_SSI1FSS);
GPIOPinConfigure(GPIO_PE4_SSI1XDAT0);
GPIOPinConfigure(GPIO_PE5_SSI1XDAT1);
  
GPIOPinTypeSSI(GPIO_PORTE_BASE, GPIO_PIN_4 | GPIO_PIN_5 );
GPIOPinTypeSSI(GPIO_PORTB_BASE, GPIO_PIN_4 | GPIO_PIN_5 );
  
SSIConfigSetExpClk(SSI1_BASE, g_ui32SysClock, SSI_FRF_MOTO_MODE_0,
SSI_MODE_MASTER, 1000000, 8);
SSIEnable(SSI1_BASE);

//Slave:
UCB1CTLW0 = UCSWRST;   // **Put state machine in reset**
UCB1CTLW0 |= UCCKPH | UCCKPL_0 | UCMSB | UCSYNC| UCMST_0;                                   
UCB1CTLW0 &= ~UCSWRST; 
UCB1IFG &= ~(UCTXIFG | UCRXIFG); 
UCB1IE |= UCRXIE;   




//Now:
//Master:
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI1);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    
GPIOPinConfigure(GPIO_PB5_SSI1CLK);
GPIOPinConfigure(GPIO_PB4_SSI1FSS);
GPIOPinConfigure(GPIO_PE4_SSI1XDAT0);
GPIOPinConfigure(GPIO_PE5_SSI1XDAT1);
  
GPIOPinTypeSSI(GPIO_PORTE_BASE, GPIO_PIN_4 | GPIO_PIN_5 );
GPIOPinTypeSSI(GPIO_PORTB_BASE, GPIO_PIN_4 | GPIO_PIN_5 );
  
SSIConfigSetExpClk(SSI1_BASE,g_ui32SysClock,SSI_FRF_MOTO_MODE_1,SSI_MODE_MASTER, 1000000, 8);
SSIEnable(SSI1_BASE);

//Slave:
UCB1CTLW0 = UCSWRST;   // **Put state machine in reset**
UCB1CTLW0 |= UCCKPH_0 | UCCKPL_0 | UCMSB | UCSYNC| UCMST_0;                                   
UCB1CTLW0 &= ~UCSWRST; 
UCB1IFG &= ~(UCTXIFG | UCRXIFG); 
UCB1IE |= UCRXIE;

  • 0
    Intellectual 440 points

    I want to know why the communication is not successful after changing the configuration. Do I need to change anything else? Can experts help me take a look? Thank you.

  • 0
    Guru 100615 points

    On the Tiva side there are some considerations with the Fss (/CS or UCSTE) signal when SPH=1 -- specifically, the case of "continuous" (FIFO never goes empty) multi-byte transactions. [At least I think so -- data sheet (SPMS429B) Table 17-3 disagrees with Sec 17.3.7.4.]

    With SPH=0 [Sections 17.3.7.3 and 17.3.7.5] Fss goes high between bytes, so every transaction is single-byte. With SPH=1 [Sections 17.3.7.4 and 17.3.7.6] Fss stays low between bytes as long as they're presented "continuous"ly (which depends on how your code is written).

    Are you using single or multi-byte transactions? You might be able to do something with FSSHLDFRM [Ref Table 17-3], which gives you partial direct control over Fss.

    [Disclaimer: My experience is with the MSP432E401Y, which is identical to the TM4C1294 (including the data sheet discrepancies). I don't use the Fss at all, rather I supply /CS (UCSTE in your case) using a GPIO, so I always know when it is asserted.]

  • 0 in reply to Bruce McKenney
    Intellectual 440 points

    Hi expert:

        Today I use ordinary GPIO to replace FSS. When TM4C sends data, the chip select signal is pulled low, and the chip select signal is pulled high after the transmission is completed. When TM4C receives data, the chip select signal is pulled low, and the chip select signal is pulled high after the reception is completed. When I configure the TM4C and MSP430 modes to Moto fmt, polarity= 0, phase= 0, they can communicate normally, proving that it is feasible to use GPIO to simulate the chip select signal FSS. When I configure the TM4C and MSP430 modes to Moto fmt, Moto fmt, polarity 0, phase 1, the system cannot communicate normally. Why is this?

       Regarding SPI mode configuration, is there any example I can refer to?Has anyone configured SPI to polarity 0, phase 1?

    Looking forward to your reply, thank you

  • 0 in reply to xi.yan.kiana
    Guru 100615 points

    We use both mode=0 and mode=3 (different targets); these don't include your case, but the latter has SPH=1. 

    We use the Fss pin, but as a GPIO, so instead of GPIOPinConfigure(<Fss pin spec>) we call GPIOPinTypeGPIOOutput(<Fss port>, <Fss pin>). We've seen nothing unusual. Almost all of the transactions are multi-byte; some use DMA.

    What is abnormal about the transactions? (Scope/Analyzer traces would be a big help.)

  • 0 in reply to Bruce McKenney
    Guru 100615 points

    > UCB1CTLW0 |= UCCKPH_0 | UCCKPL_0 | UCMSB | UCSYNC| UCMST_0; 

    I just noticed that the MSP430 side is using UCMODE=0, so the Chip Select (STE) pin is being ignored. Under ordinary circumstances this is probably fine, but with imperfect synchronization/timing, using STE to re-synchronize can be valuable. 

    > UCB1CTLW0 |= UCCKPH_0 | UCCKPL_0 | UCMSB | UCSYNC| UCMST_0 | UCMODE_2; // 4-pin, STE active low 

  • 0 in reply to Bruce McKenney
    Intellectual 440 points

    Hi expert：

    Currently my MSP430 SPI module is configured as follows：

    Currently my TM4C SPI module is configured as follows：

    TM4C is the host and MSP430 is the slave. Under this configuration, TM4C can correctly send data to MSP430, and MSP430 can correctly receive and parse it. However, when MSP430 sends the response data to TM4C, the bus data is viewed through an oscilloscope. The first frame of data replied by MSP430 should theoretically have a header of 0x55, 0x66, but 0x55 is missing. The tail of the frame should be 0x77, 0x88, but 0x77 is missing. At the same time, the number of data in this reply frame is incorrect and is less than the theoretical number. The MSP430 sending port data always shows 0x88. After that, TM4C continues to send query instructions periodically, and the MSP430 bus always shows 0x88. Why can the data be parsed correctly, but the data on the bus is incorrect when it is sent to the bus? Is there any expert who can explain whether it is due to timing or some configuration that needs to be modified?

  • 0 in reply to xi.yan.kiana
    Guru 100615 points

    On the MSP430, when writing to TXBUF, do you assure that TXIFG is set? (Not doing) that is one way to lose Tx bytes.

    I expect that the TXIFG timing would be changed by switching from SPH=0 to SPH=1 (UCCKPH=1 to UCCKPH=0).

**Attention** This is a public forum