MSP430FR5859 Hangs when using I2C in slave mode and a timer

Hi Bruce and Ryan,

Thank you for your response.

I first thought about bugs in the firmware, too, so we have a piece of test firmware that only has USCI and a timer to clarify.  Basically, in the USCI ISR, it does nothing and only responds the master with 0x00, and the timer ISR only wakes up the CPU.  We also have a GPIO output high in the main loop, and it's pulled low in the timer ISR, and that's how we know when the MSP430FR5859 hangs.  Also, when it hangs, USCI bus lines are either pulled high or low while the master is still transmitting.  Those screenshots were taken when the MSP430FR5859 was still active.  If this is caused by the ISR conflict, do you have any suggestion?

Thank you

#pragma vector=USCI_B0_VECTOR

__interrupt void USCI_B0_ISR(void)

   {

       switch(__even_in_range(UCB0IV, USCI_I2C_UCBIT9IFG))//0x1e))

       {

       case 0x00:                                          // Vector  0: No interrupts

           break;

       case 0x02:                                          // Vector  2: ALIFG, Arbitration-lost

           UCB0IFG &= ~UCALIFG;

           break;

       case 0x04:                                          // Vector  4: NACKIFG, None-Ack

           UCB0IFG   &= ~UCNACKIFG;//master

           break;

       case 0x06:                                          // Vector  6: STTIFG, START condition detected interrupt

           UCB0IFG &= ~UCSTTIFG;                       // Clear start condition int flag

           break;

       case 0x08:                                          // Vector  8: STPIFG, STOP condition detected interrupt

           UCB0IFG &= ~UCSTPIFG;                       // Clear stop condition int flag

           break;

       case 0x0A:  // Vector 10: RXIFG3    // Vector 10: RXIFG, USCI receive interrupt

           break;                                      // Reading UCBxRXBUF resets UCRXIFG

       case 0x0C:  // Vector 12: TXIFG3        // Vector 12: TXIFG, USCI transmit interrupt

           break;

       case 0x0E: // Vector 14: RXIFG2

           break;

       case 0x10: // Vector 16: TXIFG2

           break;

       case 0x12: // Vector 18: RXIFG1

           break;

       case 0x14: // Vector 20: TXIFG1

           break;

       case 0x16: // Vector 22: RXIFG0

           UCB0IFG &= ~UCRXIFG0;

           rx_buf = UCB0RXBUF;

           break;

       case 0x18: // Vector 24: TXIFG0

           UCB0IFG &= ~UCTXIFG0;

           UCB0TXBUF=0x00;

           break;

       case 0x1A: // Vector 26: BCNTIFG

           break;

       case 0x1C: // Vector 28: clock low timeout

           UCB0IFG &= ~UCCLTOIFG;

           break;

       case 0x1E: // Vector 30: 9th bit

           break;

       default:

           break;

       }

   }

#pragma vector=TIMER0_A0_VECTOR

__interrupt void TIMER0_A0_ISR(void)

{

   ticker_025++;

   __bic_SR_register_on_exit(LPM3_bits);

   DBG_PIN4_4_LOW;

}

regards,

Kevin

Hi Bruce,

In the main of the test firmware, I have fairly simple code.  The delay and the GPIO control are from the application firmware, which i forgot to remove.  I have attached the test firmware.  Please let me know if you see something inappropriate.  Thank you

while(1)

   {

       if(ticker_025_pre != ticker_025)

       {

           ticker_025_pre = ticker_025;

           __delay_cycles(80000);

           if(rx_buf%2 == 0) DBG_PINJ_1_LOW;

       }

       DBG_PIN4_4_HIGH;

       __bis_SR_register(LPM3_bits + GIE);

   }

regards,

Kevin

Hi Bruce,

I have changed the LPM3 to LPM2 in the test firmware, and the MSP430FR5859 hasn't hung yet for last two hours.  However, I am not certain if this is the cause of my issue yet.  I will have to have it run longer and on other MSP430FR5859, as well, and I will get back to you with my experiement results.  In the meantime, if you have other thoughts about my issue, please also let me know.

Thank you

regards,

Kevin