MSP430-JTAG-TINY-V2 with MSP430-CCRF problems with I2C-debugging

[KlaRa]

Hello,
I have been working since 2008 with great success with the I2C bus.
My environment: eZ430F2013 with MSP430F2013

Now I have the MSP430-JTAG-TINY-V2 and the board MSP430-CCRF Ref A with the CC430F5137 Ref E problems with debugging. The debugger hangs in Vector 4 at the location "__bic_SR_register_on_exit(LPM0_bits);". The variable "nackFlag" It has not gone through it. The value is still 0.

Code Select Expand

#pragma vector = USCI_B0_VECTOR
__interrupt void USCI_B0_ISR(void)
{
  switch(__even_in_range(UCB0IV,12))
  {
  case  0: break;                           // Vector  0: No interrupts
  case  2: break;                           // Vector  2: ALIFG
  case  4:                            // Vector  4: NACKIFG
    nackFlag = 1;
    __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
    break;
  case  6: break;                           // Vector  6: STTIFG
  case  8: break;                           // Vector  8: STPIFG
  case 10:                            // Vector 10: RXIFG
    RXdataCtr--;                           // Decrement RX byte counter
    if (RXdataCtr)
    {
      *pRXdata++ = UCB0RXBUF;               // Move RX data to address PRxData
      if (RXdataCtr == 1)                   // Only one byte left?
        UCB0CTL1 |= UCTXSTP;                // Generate I2C stop condition
    }
    else
    {
      *pRXdata = UCB0RXBUF;                 // Move final RX data to PRxData
      __bic_SR_register_on_exit(LPM0_bits); // Exit active CPU
    }
    break;
  case 12:                                      // Vector 12: TXIFG
    if (TXdataCtr)                          // Check TX byte counter
    {
      UCB0TXBUF = *pTXdata++;               // Load TX buffer
      TXdataCtr--;                          // Decrement TX byte counter
     }
    else
    {
      UCB0IFG &= ~UCTXIFG;                  // Clear USCI_B0 TX int flag
      __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
    }
    break;
  default: break;
  }
}

Does the Board without debugger is all OK. Two LEDs on the I2C IC PCF8574 lights alternately every second. Sometimes debugging works for a few rounds. But this is very rare and incomprehensible.

It follows the rest of the code.

Code Select Expand

//setup i2c
void i2cActivate() {
_DINT();                                  //Disable Interrupt

PMAPPWD = 0x02D52;                        // Get write-access to port mapping regs
P1MAP3 = PM_UCB0SDA;                      // Map UCB0SDA output to P1.3
P1MAP2 = PM_UCB0SCL;                      // Map UCB0SCL output to P1.2
PMAPPWD = 0;                              // Lock port mapping registers

P1SEL |= BIT2 + BIT3;                     // Select P1.2 & P1.3 to I2C function

UCB0CTL1 |= UCSWRST;                      // Enable SW reset
UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC;     // I2C Master, synchronous mode
UCB0CTL1 = UCSSEL_2 + UCSWRST;            // Use SMCLK, keep SW reset
UCB0BR0 = 96;                            // fSCL = SMCLK/12 = ~100kHz, 48 = 25kHz
UCB0BR1 = 0;                              // Highbyte of UCB0BR0
UCB0I2CSA = i2caddress;                   // set slave address
UCB0CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation

_BIS_SR(GIE);              // General Interrupt Enable
}


Code Select Expand

//transmit data over i2c
void i2cTransmit(unsigned char *data, int datalength, int stop) {
TXdataCtr = datalength;
pTXdata = data;

nackFlag = 0;                       // Flag zurücksetzen

UCB0I2CSA = i2caddress;
UCB0IE &= ~UCRXIE;                  // Disable RX interrupt
UCB0IE |= UCTXIE;                   // Enable TX interrupt
UCB0IE |= UCNACKIE;             // Enable NACK interrupt
UCB0CTL1 |= UCTR + UCTXSTT;         // TX-Mode enabled, start condition

    __bis_SR_register(LPM0_bits + GIE);     // Enter LPM0, enable interrupts
    __no_operation();                       // Remain in LPM0 until all data
                                            // is TX'd

if(stop) {
UCB0CTL1 |= UCTXSTP;
while (UCB0CTL1 & UCTXSTP); //ensure stop condition was sent
}
UCB0IE &= ~UCTXIE;                  // Disable TX interrupt
UCB0IE &= ~UCNACKIE;             // Disable NACK interrupt
}


Source TI samples, slightly modified: CC430F513x Demo - USCI_B0 I2C Master RX multiple bytes from MSP430 Slave

regards Klaus

   
MSP430-JTAG-TINY-V2
MSP430-CCRF Ref A with CC430F5137 Ref E
Windows 7 with CCS 6.1.1.00022
All apps and drivers up to date

[KlaRa]

Hello,
I have since the USB cable connected directly to the PC. The I2C functions run at least with a PCF8574, at least mostly. The PCF8574 is the simplest I2C IC. The DS1631 is something different. In the initialization of the IC only one byte is written. And again already hangs the debugger.

Code Select Expand

case 12:                                      // Vector 12: TXIFG
    if (TXdataCtr)                          // Check TX byte counter
    {
      UCB0TXBUF = *pTXdata++;               // Load TX buffer
      TXdataCtr--;                          // Decrement TX byte counter
     }
    else
    {
      UCB0IFG &= ~UCTXIFG;                  // Clear USCI_B0 TX int flag
      __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
    }
    break;
  default: break;
  }
}  <--- Here hangs the debugger


Console:

Code Select Expand


MSP430: Loading complete. There were 4889 (code) and 166 (data) bytes written to FLASH/FRAM. The expected RAM usage is 992 (uninitialized data + stack) bytes.
MSP430: Can't Single Step Target Program: Error during step; unknown state



The interrupt - Vector had to be rerun and "Case 12" will leave on "else".
The message: "Can not target Single Step Program: Error during step; unknown state" shows for me on a debugger error.

The USCI B0 has been throttled to about 12 kHz and the DOM to 2.45 MHz.

Code Select Expand


UCB0BR0 = 96;                            // fSCL = SMCLK/12 = ~100kHz, 48 = 25kHz
UCB0BR1 = 0;                              // Highbyte of UCB0BR0

.....

// Initialize DCO to 2.45MHz
__bis_SR_register(SCG0);                  // Disable the FLL control loop
UCSCTL0 = 0x0000;                         // Set lowest possible DCOx, MODx
UCSCTL1 = DCORSEL_3;                      // Set RSELx for DCO = 4.9 MHz
UCSCTL2 = FLLD_1 + 74;                    // Set DCO Multiplier for 2.45MHz
                                          // (N + 1) * FLLRef = Fdco
                                          // (74 + 1) * 32768 = 2.45MHz
                                          // Set FLL Div = fDCOCLK/2
__bic_SR_register(SCG0);                  // Enable the FLL control loop

It should run everything.

Help me, Klaus

[KlaRa]

Hello,
The debugger depends, as always, in the vector function. This time again in the vector 4. The variable nackFlag is 0, so it has not been set.

Code Select Expand

#pragma vector = USCI_B0_VECTOR
__interrupt void USCI_B0_ISR(void)
{
  switch(__even_in_range(UCB0IV,12))
  {
  case  0: break;                           // Vector  0: No interrupts
  case  2: break;                           // Vector  2: ALIFG
  case  4:                            // Vector  4: NACKIFG
    nackFlag = 1;                                          <--- nackFlag is 0
    __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0     <--- Here hangs the debugger
    break;
  case  6: break;                           // Vector  6: STTIFG
  case  8: break;                           // Vector  8: STPIFG
  case 10:                            // Vector 10: RXIFG
    RXdataCtr--;                           // Decrement RX byte counter
    if (RXdataCtr)
    {
      *pRXdata++ = UCB0RXBUF;               // Move RX data to address PRxData
      if (RXdataCtr == 1)                   // Only one byte left?
        UCB0CTL1 |= UCTXSTP;                // Generate I2C stop condition
    }
    else
    {
      *pRXdata = UCB0RXBUF;                 // Move final RX data to PRxData
      __bic_SR_register_on_exit(LPM0_bits); // Exit active CPU
    }
    break;
  case 12:                                      // Vector 12: TXIFG
    if (TXdataCtr)                          // Check TX byte counter
    {
      UCB0TXBUF = *pTXdata++;               // Load TX buffer
      TXdataCtr--;                          // Decrement TX byte counter
     }
    else
    {
      UCB0IFG &= ~UCTXIFG;                  // Clear USCI_B0 TX int flag
      __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
    }
    break;
  default: break;
  }
}

In CCS can be run with an F7 "Step Return". The Console then reports:

Code Select Expand

usage is 2083 (uninitialized data + stack) bytes.
MSP430: Trouble Setting Breakpoint with the Action "Continue or Finish Stepping" at 0xc0000: Address is past the end of memory


My second board of MSP430-CCRF behaves just like that.
Has the MSP430-JTAG-TINY-V2 an error?

regards Klaus

[Chester Gillon]

I think the debug problems are to do with the device entering LPM0, rather than a problem with the MSP430-JTAG-TINY-V2.


Using a MSP430-CCRFLCD with a TI MSP-FET emulator and CCS 6.1.1, with a modified cc430x513x_uscib0_i2c_08.c example also encountered errors when debugging.


If the CC430F5137 device is in LPM0 when halt the debugger then the debugger reports an invalid Program Counter value. Once in this state if attempt to resume the execution then the program fails (and have sometimes seen the CC430F5137 reset). I believe the debug failures when the CC430F5137 device is in LPM0 are due to errata EEM13 which is described in the CC430F5137 Device Erratasheet as:

EEM13 EEM Module

Function: Halting the debugger does not return correct PC value when in LPM

Description: When debugging, if the device is in any low power mode and the debugger is halted, the program counter update by the debugger is corrupted. The debugger is unable to halt at the correct location.

Workaround: None.

NOTE: This erratum applies to debug mode only.

[KlaRa]

Hello Chester

I believe the debug failures when the CC430F5137 device is in LPM0 are due to errata EEM13 which is described in the CC430F5137 Device Erratasheet

First of all thank you for the hint. This could explain a lot, but I do not think anything. I hope I can say more in two days.

regards Klaus

[KlaRa]

Hello,

I have now received a high-quality USB cable. Unfortunately, this behavior has not improved. I now check a PCF8591. This is also an old I2C module and should not be so demanding.

There is indeed a lot for the EEM13 but the hangers in the vector-function does not occur during the PCF8574.

regards Klaus

[KlaRa]

Hello,
I got to be finally clear. The OLIMEX
MSP430-JTAG-TINY-V2 was not to blame for the problems described. For details, follow the link, but in German.

https://www.mikrocontroller.net/topic/382640?goto=4387513#4387513

[KlaRa]

Hello,
The I2C problems no longer occur. Even a DS1631 running. He needed only 1.2 Kohm pull-ups.

Now I wanted to test the RF samples from TI under the CCS 6.1.1. Not running! Occur when debugging errors as previously described in the I2C tests. Chester Gillon had also experienced something.

Using a MSP430-CCRFLCD with a TI MSP-FET emulator and CCS 6.1.1, with a modified cc430x513x_uscib0_i2c_08.c example also encountered errors when debugging.

Then I used the IAR 6.40.1 and tested the OLIMEX samples. It runs!

The IAR I had used years ago already. Then came the CCS and the well-liked me. Now I have to say, the IAR makes a better impression. Before operating the DS1631 with the 1.2 Kohm pull-ups came under the CCS on interest. The IAR there was stable, you could debug at least.

Is that the reason why providing OLIMEX professionals IAR Examples?
I was surprised also that the IAR OLIMEX directly supported.
regards Klaus