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.
#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.
//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
}
//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
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.
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:
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.
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
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.
#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:
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.(https://www.olimex.com/forum/Smileys/default/cry.gif)
Has the MSP430-JTAG-TINY-V2 an error?
regards Klaus
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 (http://www.ti.com/lit/pdf/slaz094) as:
QuoteEEM13 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.
Hello Chester
QuoteI 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
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
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
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.
Quote from: Chester Gillon on December 05, 2015, 08:15:54 PM
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