• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 410 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.

MSP430F5438A I2C SCL timing is correct using debugger, much longer when not

Engineer1
Intellectual 660 points

Other Parts Discussed in Thread: MSP430F5438A

We are able to write to an I2C device with no problem, but the issue is that SCL runs at an incorrect (slower) speed when not in debugger mode.  When in debugger mode SCL clocks at the correct rate.  The problem occurs even if no I2C device is connected (only a pullup resistor exists on SCL and SCA).  You may be able to duplicate the problem using other conditions, but our specific conditions are:

 o  MSP430F5438A rev D in Experimenter Board.

o  Pullup resistors on SCL (P3.2), SCA (P3.1): 3.3K

o  SMCLK = 1.8432 MHz.

o  UCB0 sourced from SMCLK, Transmit mode.

o  UCB0BRW = 6, so SCL freq should be 1.8432MHz/6 = 307.2 kHz, so T_low = T_high = 1.63 us.

o  MSP430F5438A is I2C master in transmit mode, 7-bit addressing.

o  Slave address = 0x0038 (loaded into UCB0I2CSA).

 Measured SCL T_high = T_low = 1.6 usec when in debug mode thru FET tool (either continuous run mode or stepping through) which is correct, but when debugger exits and the board is reset, the SCL high and low times are about 4.3 usec as captured on a storage scope.  These SCL clock periods remain the same whether any I2C device is connected to the bus or not (you should be able to observe SCL even if there is no ACK from another device).

Please let me know if you are able to observe the SCL high and low times with and without the debugger on an MSP430F5438A Experimenter Board, and if they are correct in debug mode and still correct standalone (after hardware reset or power cycling).

This problem is insidious because everything works correctly when in debugger mode, but when not in debugger mode it runs differently (SCL is almost 3x slower, but still functions correctly other than the speed drop).  So it *seems* as if everything is working fine; unless you go back after exiting the debugger and detect the slow SCL clock you might never know there is a problem.

Can you duplicate this problem? (slower-than-normal SCL rate when not using debugger)

  • 0
    Intellectual 660 points

    Update Aug. 9, 2013: The problem seems to be code-dependent, and has not occurred since changing the code to clear the UCB0 I2C peripheral before each write.  Previously it was cleared only prior to configuration of any I2C registers.

    The problem is no longer occurring -- the timing is now correct both within the debugger and standalone.

    I would encourage anyone writing to the I2C in master TX mode to observe SCL timing on a storage scope outside the debugger as well as during debugging, and please report it here if you observe incorrect SCL timing outside the debugger but correct timing while using the debugger.

  • 0 in reply to Engineer1
    Intellectual 660 points

    I should clarify that by "clear" I meant "reset" the UCB0 I2C peripheral by setting UCSWRST in UCB0CTL1, then clearing it.

  • 0 in reply to Engineer1
    Guru 227245 points

    It would be interesting to see your clock system setup code.
    It is possible that you do something wrong there (e.g. proceeding before a crystal is up and running) and when the debugger is attached, it just gives this bit of additional time to make things work. While without this, the timing is still wrong when the I2C hardware requests the clock.
    It is just a wild guess, but it is a known fact that the debugger interferes with the clock system and while this often causes unexpected bugs, this time it seems to fix a bug in your code.

  • 0 in reply to Jens-Michael Gross
    Intellectual 660 points

    The code clears, then tests XT1LFOFFG until it remains clear, which we have timed to take about 500 msec for our 32.768 kHz crystal.  We thought of the same thing you pointed out, and configured the NMI interrupt to turn on some LEDs then wait for ever if XT1LFOFFG (and OFIFG) ever became set.  This XT1LFOFFG trap was tested by momentarily grounding one side of the 32.768kHz xtal while running -- it entered the trap immediately.  But it never entered the trap when the code was running, so it appears it was not a crystal osc. issue.

    Also, SMCLK (which was driving the I2C) was monitored and was at correct frequency when the longer-than-normal SCL periods were observed.

    In any case the SCL timing appears to be correct now.  I will report this here again if the elongated SCL periods re-appear.

**Attention** This is a public forum