• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 711 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.

Program execution breaks on __delay_cycles

tml
Expert 1140 points

Hi,

I adapted the I2C master TI example code (http://coecsl.ece.illinois.edu/ge423/datasheets/MSP430Ref_Guides/Cexamples/MSP430G2xx3%20Code%20Examples/C/msp430g2xx3_uscib0_i2c_12.c) and initially everything was working ok, but when I got back after a few hours of break it stopped working, althought the code has not changed: the program execution stops on the __delay_cycles(4600) call line. I've confirmed it with P1.4 that I monitor on the logic analyzer.

The function that is disturbed is called from the main() and looks like:

void get_temperature_data()  {
  P1OUT |=BIT4;    // <- brings high state on P1.4
  PTxData = (unsigned char *)utTxData; // send control reg and temp reg
  TXByteCtr = 2;
  //Transmit process
  Setup_TX(SLAVE_ADDR);
  __delay_cycles(1000);
  Transmit();
  while (UCB0CTL1 & UCTXSTP); // Ensure stop condition got sent
 P1OUT &=~BIT4;     // <- still OK, it sets zero on this line
 __delay_cycles(4600); 

 P1OUT |=BIT4;          // <- does not set high level :( But if I comment the __delay_cycles in the line above out I can see that P1.4 is high

 PTxData = (unsigned char*)msbData; // send control reg and temp reg
...
}

I supposed LPM0 occured during execution of __delay_cycles(4600), but I disabled all CPUOFF's from the code. Decreasing 4600 to for example 100 gives the same result as if there were no __delay_cycles() call.

Can you give me a hint what might be a problem here?

Best Regards,

tml

  • 0
    Expert 1140 points

    Any ideas?

    Best Regards.

    tml

  • 0 in reply to tml
    Prodigy 70 points

    Maybe two things:

    1. In your adapted version, is the watch dog timer still disabled?
    2. A silicon bug, check the device Errata sheet. There are few bugs related about what instruction sequences you have, etc. You might have to look at the disassembly to verify some of these. What happens if you replace "__delay_cycles(4600);" with "{ volatile int i = 4600; while(i-- != 0) _NOP(); }"?
    Another thing you should do is, run this in the debugger, and add a break point at on the first executable line of code in main(). If there is a memory corruption, or a watchdog reset, the program will automatically reset and restart from main(). Thus if you put a break point there, it should only ever high it the first time you run the software, and if the CPU is being reset.
  • 0
    Guru 227245 points

    tml said:
    I supposed LPM0 occured during execution of __delay_cycles(4600)

    Going into LPM0 requires CPU action. And during a delay, the CPU is runnin in circles, doing nothing else. Of course an ISR ocul enter LPM while the main code executes the delay. But this would be very unusual coding then.

    It's likely that you get a buffer overrun in your code and after some time, you store data on the stack, messing it up and crashing the CPU. Or you enabled RX interrupts and when one comes, it isn't handled and the ISR runs in cicrles until it is done (which never happens), freezing the main code.

    Without knowing the complete code, there are many, many possibilities, one as likely as the others.

**Attention** This is a public forum