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.

MSP430FR5969 Launch Pad with Sharp96 doesn't work

Other Parts Discussed in Thread: MSP430FR5969, MSP-EXP430FR5969, CC2650STK

I bought the MSP430FR5969 Launch Pad with Sharp96 Booster pack. Using IAR I built the 430BOOST-SHARP96-GRlibExample project with no problems. When I launch the code from main using the built in debugger it calls function GrFlush() then appears to do a reset. It doesn't get to the functions that write on the LCD screen below te above mentioned function in main(). Did this ever work?

  • Hello Ralph,

    I tried to replicate your problem but was able to properly program my device without any issues. Have any modifications been made to the MSP-EXP430FR5969 or 430BOOST-SHARP96 hardware? Make sure that the BoosterPack is correctly oriented and connected to the LaunchPad. Can you please further describe the behavior you are experiencing? So the code correctly gets through the other graphics functions before GrFlush but never gets to the functions afterwards? What makes you think that a reset is involved? Have you tried using the CCS project/build instead?

    Regards,
    Ryan
  • Ryan,

    Thanks for getting back to me.

    I believe the Sharp96 BOOSTER Pack is properly oriented on the Launch Pad Board. J2 of the Sharp96 bd. is attached to J5 of the Launch Pad bd. J1 of the Sharp96 bd is attached to J4 of the Launch Pad Bd with the Rocket on the Sharp96 Bd pointing towards the Launch Pad JTAG connector. GND of the 430BOOST-SHARP96 is attached to GND of the MSP-EXP430FR5969 and VCC is attached to both boards.

    No modifications have been made to either MSP-EXP430FR5969 or 430BOOST-SHARP96 boards. On the built in JTAG using IAR v7.30, in main() I can single step through the graphic init functions then when I get to GrFlush() and try to either single step through or over it the JTAG never comes back. Just as an experiment I put a breakpoint at main(). Did a 'go' hit the break. did another go and hit the same break which means when it got to GrFlush() something happened and it came back around to main(). Obviously it reset.

    Nothing on this board seems to work. in the OutOfBox project the back channel UART doesn't work. Corrected, the flashing LEDs work. After Uart_Init() I just put a loop to send a 'U' to the UART transmitter.

        // Board initializations
        Init_GPIO();
        Init_Clock();
        Init_UART();

        while(1)
        {
          EUSCI_A_UART_transmitData(EUSCI_A0_BASE, 'U');
        }      
    Nothing comes out of TX. The schematic shows back channel TX on one of the J3 JTAG pins. Using a scope I see nothing. Single stepped through the underlying assembly code. It looks proper. Can see it's waiting for the transmitter empty and the 0x55 being issued to the TxBuff register but nothing coming out to a pin. I'll try the other UART on p2.5. Can you point me to a register user's guide for the MSP430FR5969? I have the User's guide for the MSP430x5xx and MSP430x6xx Family. Are the base addresses and offsets the same? Sort of working in the dark.

    What is the base address of the A0 and A1 UARTS? I only have IAR. Don't have CC.

    Thanks

    Ralph Sweitzer

  • Ralph,

    This is quite odd behavior since there is nothing in the GrFlush function that would cause a software reset. This would almost indicate that the reset is occurring externally, through hardware via the RST pin. Please make sure that this pin is not shorted to any other trace on the board, either on the LaunchPad or BoosterPack. You could use an oscilloscope to see if the RST pin is pulled on any during the GrFlush function.

    So you can't get the Out of Box demo to communicate with the GUI either? UCA0 is connected to the backchannel UART which can communicate to a PC via the eZ-FET, UCA1 is accessible through the header pins P2.5 and P2.6 on J4. The Out of Box demo uses UCA0 while the 430BOOST-SHARP96 uses UCA1. I believe that UCA1 is operating correctly since several commands are sent to the LCD before getting stuck at GrFlush. Enhanced Universal Serial Communication Interface (eUSCI) – UART Mode is covered in Chapter 21 of the FR5969 User's Guide (SLAU367): www.ti.com/.../slau367g.pdf

    If using UCA0 backchannel UART to communicate with your PC through a COM port terminal, make sure that you are initialized with the same baud rate on both ends and that the terminal is connected to the MSP Application UART1 COM port. There is the possibility of a IAR library bug which I am not seeing with my CCS build, the free version of CCS can be provided on the following web page and should allow enough memory to run the LCD demo: www.ti.com/.../ccstudio

    Regards,
    Ryan
  • Hi Ralph,

    Any updates on your MSP-EXP430FR5969 & 430BOOST-SHARP96?

    Regards,
    Ryan

  • Ryan,

    I tried loading CCS for the MSP430. No luck. It doesn't hang on GrFlush() anymore or go through reset like using IAR but nothing comes on the LCD screen. I think I have bad HW. Can you point me to any SPI code. Init, interrupt, read, write, etc.. Also do you have a BOOSTER card that does gyro, at least 3 axis tilt?

    Thanks

    Ralph

  • Ralph,

    Agreed that faulty HW appears to be the culprit. Were these boards modified in any way before use or are they brand new out of box? Here's a link to the MSP430FR59xx Code Examples package, for which SPI is included: www.ti.com/.../slac536

    There are no specific BoosterPacks developed for gyro control with an MSP430, however there are several I2C/communication examples for gyro devices like the IMU-3000, ITG-3200, and MPU-9150 found on the E2E forum and various DIY communities/blogs. TI EVMs with on-board gyroscopes include the BOOSTXL-SENSHUB and CC2650STK.

    Regards,
    Ryan
  • Hi Ryan,

    Can you help me with SPI on the MSP430FR5969? I have limited experience with SPI. I set the chip up for SPI. I can write a byte or series of bytes. Below is the code I swiped off another site but it works. Its messy. Writing over SPI is easy but its the reading data is confusing. I give the chip a command via the SPI write then I want to read its reply. How do I do that? I'm using SPI master and I believe 3 wire (MOSI, ISO and SCLK) with a GPIO used as chip select to the particular chip. What role does UCxSTE play. What would be the sequence to initiate a read from the device?

    If I assert chip select and start the clock how does the slave chip know to start sending in its data versus thinking the master (MSP430FR5969) has data?

    Thanks

    Ralph

    void spi_init(void)
    {
        P1SEL0 &= ~BIT3; // UCB0STE
        P1SEL0 &= ~BIT6; // UCB0SIMO
        P1SEL0 &= ~BIT7; // UCB0SOMI
        P2SEL0 &= ~BIT2; // UCB0CLK

        P1SEL1 |= BIT3;  // UCB0STE
        P1SEL1 |= BIT6;  // UCB0SIMO
        P1SEL1 |= BIT7;  // UCB0SOMI
        P2SEL1 |= BIT2;  // UCB0CLK

        PM5CTL0 &= ~LOCKLPM5;

        CSCTL0_H = CSKEY_H;
        CSCTL1 &= ~DCORSEL;
        CSCTL1 = (CSCTL1 & ~0x000e) | DCOFSEL_0; // 1 MHz
        CSCTL3 |= DIVA__1 | DIVS__1 | DIVM__1; // clock dividers = 1
        CSCTL0_H = 0;

        UCB0CTLW0 |= UCSWRST;
        UCB0CTLW0 |= UCCKPH;
        UCB0CTLW0 |= UCCKPL;
        UCB0CTLW0 |= UCMSB;
        UCB0CTLW0 |= UCMST;
        UCB0CTLW0 |= UCMODE_2;
        UCB0CTLW0 |= UCSYNC;
        UCB0CTLW0 |= UCSSEL__SMCLK;
        UCB0CTLW0 |= UCSTEM;
        // UCB0STATW |= UCLISTEN; // OK, if enabled i receive what i send
        UCB0CTLW0 &= ~UCSWRST;

        UCB0IE |= UCRXIE;

        _enable_interrupts();

    }

    void spi_write(unsigned char *ptr, unsigned int len)
    {
        while(len != 0)
        {
            while (!(UCB0IFG & UCTXIFG));
            UCB0TXBUF = *ptr++;
            len--;
        }         
    }

    #pragma vector = USCI_B0_VECTOR
    __interrupt void isr_usci_b0 (void)
    {
        static volatile int received = 0;
        switch (__even_in_range(UCB0IV, USCI_SPI_UCTXIFG)) {
        case USCI_NONE:
            break;
        case USCI_SPI_UCRXIFG:
            received = UCB0RXBUF;
            UCB0IFG &= ~UCRXIFG;
            _no_operation();
            break;
        case USCI_SPI_UCTXIFG:
            break;
        }
    }

  • Hi Ralph,

    UCxSTE is a does not play any role in 3-wire SPI communication. Reading data from a slave device can either come through a request from the master or automatically as needed, this all depends on the type of slave device being used. There are no SPI protocols for initiating a read from the slave device, although the USCI ISR is designed to receive any data sent by the slave at any moment. SPI has dedicated data in/out lines meaning that transmitting/receiving can occur simultaneously. Are you still trying to communicate with the 430BOOST-SHARP96 BoosterPack? There are several GRLib and general FR5969 SPI examples provided in MSPWare.

    Regards,
    Ryan
  • Ryan,

    I need some advise. I have a part that when a read over I2C occurs it requires a write with a register address followed by a read.  This requires a START for the initial write (device adr (W). with register adr) immediately a repeated START for the read (device adr (R)) then read bytes.  I can write to the part. Looks good on the scope. I follow the write with a read and get zeros. The following is my I2C driver code. Please advise

    -Ralph

    // Initialize the MCU I2C interface
    void i2c_init( void )
    {

      UCB0CTL1 |= UCSWRST;                          // put eUSCI_B in reset state
      P1SEL1    |= SDA + SCL;
      UCB0CTLW0 |= UCMODE_3 + UCMST;                // I2C master mode, SMCLk
      UCB0BRW    = 10;                              // baudrate = SMCLK / UCB0BRW --> 100 KHz
      UCB0CTL1 &=~ UCSWRST;                             //clear reset register

    }

    // I2C WRITE
    void i2c_write( unsigned char* txdPtr, unsigned short len, unsigned char d_adx)
    {

      UCB0I2CSA = d_adx;
      TXData= txdPtr;
      TXByteCtr = len+1;                              // Load TX byte counter

      UCB0IE |= UCTXIE0 + UCNACKIE;                   //transmit and NACK interrupt enable

      while (UCB0CTLW0 & UCTXSTP);                    // Ensure stop condition got sent
      UCB0CTLW0 |= UCTR;
      UCB0CTLW0 |= UCTXSTT;

    //  __bis_SR_register(LPM0_bits + GIE);            // Enter LPM0 w/ interrupts
      __bis_SR_register(GIE);            // Enter LPM0 w/ interrupts
     __no_operation();                               // Remain in LPM0 until all data

    }

    // I2C READ
    void i2c_read(unsigned char* rxdPtr, unsigned short len, unsigned char d_adx)
    {

      UCB0CTLW0 &= ~UCTXSTT;
      UCB0I2CSA = d_adx;
      TXData= rxdPtr;
      TXByteCtr = 1;                                  // Load TX byte counter

      UCB0IE |= UCTXIE0 + UCNACKIE;                   //transmit and NACK interrupt enable

      while (UCB0CTLW0 & UCTXSTP);                    // Ensure stop condition got sent
      UCB0CTLW0 |= UCTR + UCTXSTT;

    //  __bis_SR_register(LPM0_bits + GIE);           // Enter LPM0 w/ interrupts
      __bis_SR_register(GIE);           // Enter LPM0 w/ interrupts
      __no_operation();                               // Remain in LPM0 until all data

      RXData= &rxdPtr[1];
      RXByteCtr = len;

      UCB0IE |= UCRXIE + UCNACKIE;

      while (UCB0CTLW0 & UCTXSTP);                     // Ensure stop condition got sent

      UCB0CTLW0 &= ~UCTR;
      UCB0CTLW0 |= UCTXSTT;

    //  __bis_SR_register(LPM0_bits + GIE);             // Enter LPM0 w/ interrupts
      __bis_SR_register(GIE);             // Enter LPM0 w/ interrupts
      __no_operation();                               // Remain in LPM0 until all data

    }
    // Interrupt service routine
    #pragma vector = USCI_B0_VECTOR
    __interrupt void USCIB0_ISR(void)
    {
      switch(__even_in_range(UCB0IV,0x1a))
      {
        case 0x00: break;                           // Vector 0: No interrupts break;
        case 0x02: break;
        case 0x04:
          UCB0CTLW0 |= UCTXSTT;                     //resend start if NACK
          break;
        case 0x16:
          RXByteCtr--;
          if (RXByteCtr)
          {
            *RXData++ = UCB0RXBUF;                  // Move RX data to address PRxData
          }
          else
          {
            *RXData++ = UCB0RXBUF;                  // Move RX data to address PRxData
            UCB0CTLW0 |= UCTXSTP;
            UCB0IFG &= ~UCRXIFG0;
            __bic_SR_register_on_exit(LPM0_bits);   // Exit LPM0
          }
          break;
        case 0x18:
          if (TXByteCtr)
          {                          // Check TX byte counter
            UCB0TXBUF = *TXData++;                  // Load TX buffer
            TXByteCtr--;                            // Decrement TX byte counter
          }
          else
          {
            UCB0CTLW0 |= UCTXSTP;                   // I2C stop condition
            UCB0IFG &= ~UCTXIFG;                    // Clear USCI_B0 TX int flag
            __bic_SR_register_on_exit(LPM0_bits);   // Exit LPM0
          }
          break;                                    // Vector 26: TXIFG0 break;
        case 0x1a:
          UCB0IFG &= ~UCBCNTIFG;
          break;
        default: break;
      }
    }


  • Ralph,

    It sounds like you have a pretty good system implemented for debugging your system. Are you confident that the write commands are working exactly as expected and that the issue lies with reading? Are you sending the proper slave read address? Are you getting the proper ACKs from the slave device? Does the RXIFG ever get serviced, and does your code hang somewhere unexpectedly? What slave device are you using? Perhaps providing some o-scope screen shots would also be beneficial for debugging.

    Regards,
    Ryan
  • Hi Ryan,

    Using the TI MSP430FR5969 LaunchPad. I have an I2C driver. I have a LIDAR peripheral that has an I2C interface but is powered at 5v. Can I pull-up the MSP430FR5969 SCL and SDA I2C lines to 5v?

    Also, On the LaunchPad board which is powered by the USB's 5v. Where can I pick that off on the board?

    Thanks

    Ralph Sweitzer

  • Hi Ralph,

    MSP devices only support a maximum of 3.6 V, therefore you will need to use a voltage level translation device to interface with the 5V LIDAR peripheral. The MSP-EXP430FR5969 has 5V available on the 5V jumper on the J13 isolation block and on the test pin to the right of the VCC BoosterPack header.

    Regards,
    Ryan
  • Hi Ryan,

    Need your advise and help. I'm using the MSP430FR5969. I want to measure pulse widths that come every 10ms. The pulse widths can vary anywhere from 10us to 5ms. My Launch Pad chip is running 16 mhz. I believe I want to capture and compare from the signal coming in on GPIO input line.

    The following is my clock setup code.

    void clock_init(void)
    {
            // Clock System Setup
        // ---------------------------------------------------------------------
        CSCTL0_H = CSKEY >> 8;                    // Unlock CS registers
        CSCTL1 = DCOFSEL_4 | DCORSEL;             // Set DCO to 16MHz
        CSCTL2 = SELA__VLOCLK | SELS__DCOCLK | SELM__DCOCLK;  // Set SMCLK = MCLK = DCO
                                                  // ACLK = VLOCLK
        CSCTL3 = DIVA__2 | DIVS__1 | DIVM__2;     // Set all dividers to 1
        CSCTL0_H = 0;                             // Lock CS registers
        // ---------------------------------------------------------------------

    }
    Do have any code that I could use or look at to achieve what I want. Having a hard time getting my brain around it. I've done some experiments with the clock and a timer A0 tick. At 16mhz the fastest I can go is 410us, at 24mhz its 52 us.

    Please advise and point to some code that will do what I want.

    Thanks

    Ralph

  • Hi Ralph,

    Assuming that you are sourcing TA0 with SMCLK at a maximum 16 MHz it goes to follow that you should be able to measure pulses of down to 62.5 ns.  The device datasheet further specifies that the minimum input pulse duration required for capture is 20 ns so your application is feasible.  It all depends on the way you are initializing your TA0 registers.  Since you are trying to measure pulse width instead of period you will want to capture on both rising/falling edges and utilize timer interrupts to record the length of time that has passed in between edges.  Here is my timer initialization for a similar application:

    	// TA1 counts the pulse length on the communication line
    	TA1CCTL1 = CM_3 | CCIS_0 | SCS | CAP | CCIE;
    	// Capture rising/falling edges,
    	// Use CCI1A=P1.2/TA1.1,
    	// Synchronous capture,
    	// Enable capture mode,
    	// Enable capture interrupt
    	TA1CCTL1 &= ~COV;							// Reset capture overflow
    	TA1CTL = TASSEL__SMCLK | MC__CONTINUOUS;  	// SMCLK, Continuous mode
    	TA1CTL |= TACLR;							// Reset counter

    On the first TA1 interrupt (rising edge) I would reset the timer counter.  The next interrupt would be from a falling edge and I would record the value of TA1CCR1 and reset the timer counter timer to start all over again.  The length of the pulse would be determined by TA1CCR1 multiplied by the period of the timer clock source.

    Regards, Ryan

**Attention** This is a public forum