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.

Port Damage I2C MSP430G2553

Other Parts Discussed in Thread: MSP430G2553, STRIKE, TRF7970A

Using MSP430G2553

Up to 10 PCBA'a in a daisy chain. Short 4" cables in between. Power / ground is also daisy chained. Voltage drop on power is 30mV through all board (not each). Local regulation would keep grounds within 15 mV 

I2C port (P1.6 , P1.7) pins are being damaged, All MSP devices are set up as "slave" 

Seems that, intermittently when long chains are put together and powered on one unit will fail and others will be damaged in the process.

Validation Test -

On a good board programming the port as output and toggling we see expected square wave.

If a board fails then when we put in toggling test code P1.7 (SDA) does not toggle and P1.6 (SCL) also does not toggle and is pulled down 1/2 to 3/4 volt from rail. 

The test code sits above the I2C setup routines and simply forces Port 1 to be output and toggle all bits high then low in a While(1) loop.

Seems that after proving the code with a known good board a bad board output is acting like it is programmed as input with pull up.

If we test the same P1.6 & 1.7 pins as input and they function normally. only output driver appears damaged

We have tested by bringing up chains of boards one by one and if there is a failure not only is the last in the chain found to be defective but others are as well. Not necessarily adjacent modules. If a faulty module is introduced into a working series of modules failures occur in that chain.

Power is applied and removed before any cables are disconnected or re-connected between module - NO HOT PLUGGING

There does not appear to be a significant current draw nor are any parts getting warm - no evidence of short circuit.

Is there some mechanism that could cause the I2C to fail in this manner such that the port output driver could be damaged? 

Is there some race condition possible on initialization of the I2C?

If there were over current into one of the I2C pins would the failure not cause excessive current flow?

  • Does "daisy chain" mean that all devices share the same bus, or that each device has two I²C ports and acts as a bridge? In the first case, what is the overall length of the bus, and what frequency are you using?
  • All devices drop on 1 I2C port so the MSP is NOT a bridge device.

    The length of the bus is several feet. 10 devices with 4" cable in between.

    the speed is about 40 KHz and the waveforms, while rounded, do make a complete "top" of the 3.3 volt rail 

    In any event there are several hundred out in the field that do not fail. This is a recent phenomenon in the assembly area. ESD is controlled and the humidity here has been high. Seems that we can program and test the boards one at a time and things appear to be fine. then when we assemble the chain of 10 there is a failure that appears to damage more than one PCBA

  • ESD is controlled

    Well, all the evidence indicates it's not.

    (As a rule of thumb, a GPIO's internal ESD protection can handle anything that happens on the board, but an external I/O connection requires more protection.)

  • ESD (human model) is maybe controlled, but hey - you are connecting quite long wires - not only data but power too. Note that for example all USB chips have internal ESD protection diodes on D+/D-, yet to properly protect USB ports, TVS diodes close to connector are mandatory components. You shall consider similar to USB protection, solution - two data lines and power too. Additional reading

  • Lets focus on other possible causes - PLEASE.
  • Using Wurth 824021 TVS

    YES IT IS!
  • Lets focus on other possible causes

    What other possible cause could there be?

    The problem happens to multiple devices, at the pins that are connected to the bus. So it must be something that happens on this bus. So it's either ESD, or something else that you're doing on the bus (maybe a wrong power-up sequence).

    But nobody here knows your circuit.

  • >Lets focus on other possible causes - PLEASE.
    Lightning? (KIDDING)

    Mentioned power sequence could be cause. You shall ensure that GND and VCC is connected first, only then i2c lines - the same as USB connectors do.

  • Funny ;-D (but maybe the problem device is in Florida - but alas we can replicate the problem here is san diego,)1470-001 Rev D I_O page.pdf

    Anyway the circuit on the I2C is pretty simple there are 2 connectors 1 - in and 1 - out. there is an NXP I2C buffer IC that can be used or can be bypassed with jumper resistors (U12 - not installed  when bypassed) there are Wurth Low capacitance (<70pF) TVS diodes on each of the SDA and SLK with the MSP tapping the I/O. Each of the MSP's in the chain is a slave with a given address. The NXP is installed as the first in the chain of 10 otherwise is is not installed.

    I have attached the I/O schematic page with the only other connection being to the MSP I2C pins P1.6 and P1.7 

    Power is turned on via 12 volt supply with each board having it's own local regulator so all device power up concurrently

    where is the "attach" button - I wanted to send that PDF schematic page  but can't seem to find it here?? I think I found it - this could be more "apparent"

  • >but alas we can replicate the problem here is san diego
    Why not. First I would ask - did they "hot-plug" boards while power is on? You could try to "hot-connect" slave boards with ground failure - connect all lines including 12V but ground and see how well slave board charge it's supply capacitors through i2c lines. Maybe TVS are doing job well, but who knows..

    Note that absolute maximum negative voltage on any I/O pin of msp430 is -0.3V, but TVS 824021 forward voltage is 1V  0.8V at just 15mA, buffer is able to provide 50mA on i2c bus which is more than needed for msp430 pin to be dead

  • Ok let say it is ESD.

    What would you do to prevent damage?

    Assume we need to survive a near by lightning strike and we have all the filtering we can muster system wide - nothing else is being damaged in the whole system. There are several PC's and PLCs including a netduino controller. There are also 2 commercial power supply and 2 LDO's between the AC and the and the I2C line. There is NO hot plugging going on. Also note there is no power loop the power is fed from one device to the next in the chain each device with local LDO. there is less than 30mV difference between the first unit in the chain and the last.
    These devices are powered 24/7 in most applications
  • > There is NO hot plugging going on.
    Sure. People do not make mistakes and if they do - they always tell you. And all the wiring and connectors do not fail, ever. :D

    This could be the case of GND fail while GND of unpowered slave board collects last. This is only scenario I can imagine for your circuit at the moment. You shall test this scenario in your lab unless you have better idea of what's wrong.

    >Ok let say it is ESD.
    What class of ESD protection are you aiming at? As you name PLC then it's industrial application, shall be better than HBM, I would say TLP. Oh, and you cannot guess about ESD or verify it in the forum. You shall TEST it - using ESD tester. When your device and all it's open parts including contactors survives ESD tests - only then you can be sure that ESD is ok.

  • D Galli,

    One thing to keep in mind when powering a daisy chained group of boards like this (shared voltage rail, LDO on every board), is that the LDOs will all power up at slightly different times, which means all the MSP430s will power up at slightly different times as well.  Depending on what all is connected between 430's on separate boards (including the I2C lines), one 430 could be power up and starting to execute code (driving IOs or letting SDA/SCL pull high) while the 430 it is connected to still does not have VCC ramped up all the way.  This could potentially lead to a violation of the maximum voltage allowed on a pin spec (-0.3V to Vcc + 0.3V) for the unpowered 430.  Violating this spec could potentially damage the device.  You could try doing a long delay at the beginning of the program for each 430, with the GPIOs all set as high impedance, to give the other devices time to ramp up VCC.

    Also, we have a System Level ESD Considerations app note.  If you haven't already, I recommend taking a look and seeing if there are any additional recommendations you can apply to your system (you only posted a portion of the schematic, so I can't tell what you have already included).  I don't know for sure that ESD is the root cause, but in a system like yours (multiple board daisy chained), I would STRONGLY recommend including ESD protection on the connectors.

    Mike

  • Ahhh - Refreshing

    We do have the ESD part number wurth 824021.

    I will forward on the delay turn on information and see what happens.
    The FW designer should have this tried out in the next day or so.

    Thanks - This sounds like a candidate
  • Mike Pridgen said:
    This could potentially lead to a violation of the maximum voltage allowed on a pin spec (-0.3V to Vcc + 0.3V) for the unpowered 430.  Violating this spec could potentially damage the device.

    Well, this can happen only if i2c pull-up resistors are sized for current which exceeds I/O protection diode max current, 2mA.

    [edit] p.s. good luck with delays :)

  • So it would appear that there is a 500 mS delay on startup. The FE developer has sent this code snippet from his project on the initialization of the hardware. I cannot see anything that is amiss but I am not a firmware guy. Maybe you can inspect and find a clue


    void main(void)
    {
    // Stop Watchdog timer
    WDTCTL = WDTPW + WDTHOLD; // stop watchdog timer

    // set the DCO to 8 MHz
    McuOscSel(1);

    // Configure the Flash Clock Generator
    FCTL2 = FWKEY + FSSEL_1 + FN4 + FN2; // Clk = SMCLK/22 = 363 KHz

    // Give Module time to get up and running, time for everything to power up
    McuDelayMillisecond(50);

    // settings for communication with TRF7970A
    Trf7970CommunicationSetup();

    // Set Clock Frequency and Modulation
    Trf7970InitialSettings();

    // Set LED Port and Turn Off
    LED_PORT_SET;
    LED_ALL_OFF;

    // Assign MB Address Complete
    MBADDRESSEND_OFF;
    MBADDRESSEND_PORT_SET;

    // Test Wait for Output to setup
    McuDelayMillisecond(10);

    // Assign MB Address Start
    MBADDRESSSTRT_EDGE_SET;
    MBADDRESSSTRT_PIN_SET;
    MBADDRESSSTRT_RES_SET; // Try to set this as a pull down resistor
    MBADDRESSSTRT_RES_DOWN;

    // For Trigger to indicate Pill Drop Update
    STATE_1_CHANGE_SET;
    STATE_1_CHANGE_OFF;

    // For Trigger to indicate RFID Update
    STATE_2_CHANGE_SET;
    STATE_2_CHANGE_OFF;

    // Set Motor Output
    MOTOR_PORT_SET;
    MOTOR_OFF;
    motorRunningFlag = 0x00;

    // Set flag to 1 so can do one address set
    setI2CAddFlag = 0x01;

    // Set Pill Sensor
    PILLDROP_PIN_SET;
    PILLDROP_EDGE_SET;

    // Temp values
    motorOffOrOn = 0x00;
    motorOnTime10ms = 15; // 150ms
    motorOffTime10ms = 25; // 250ms

    // Setup Clock Timer for the PWM Motor Output
    TA1CCTL0 |= CCIE;
    TA1CCR0 |= 10000 - 1; // Set Freq to 8MHz/10K = 800HZ
    TA1CTL = MC_0;

    // Disable
    IRQ_OFF;

    // Wait 500 ms for Photo Diodes to power up
    McuDelayMillisecond(500);

    // Retrieve the Current I2C address
    I2CAddress = 0xFF & flash_read((char *)0x1080);

    // For feedback pullse the Red LED the address number of times
    // AA 1-22-16 Treat Default address of 0x3F as normal address
    u08_t index = 0;
    for (index = 0x00; index < I2CAddress; index++)
    {
    LED_RED_ON;
    McuDelayMillisecond(25);
    LED_RED_OFF;
    McuDelayMillisecond(25);
    }

    // Clear all Interrupt status prior to enabling interrupts
    PILLDROP_CLR;
    DISABLE_TRF;
    MBADDRESSSTRT_CLR;
    PILLDROP_ON;
    MBADDRESSSTRT_ON;

    // General enable interrupts
    __bis_SR_register(GIE);

    // Setup I2C communication
    I2c_setup(I2CAddress & 0xFF);

    Etc…………..


    //
    // Set up initial condition for I2C communication on MSP430G2553
    //
    void I2c_setup(unsigned char slave_address) {
    P1SEL |= BIT6 + BIT7; // Assign I2C pins to USCI_B0
    P1SEL2 |= BIT6 + BIT7; // Assign I2C pins to USCI_B0
    UCB0CTL1 |= UCSWRST; // Enable SW reset
    UCB0CTL0 = UCMODE_3 + UCSYNC; // I2C Slave, synchronous mode
    UCB0I2COA = slave_address; // Own Address is 0x28
    UCB0CTL1 &= ~UCSWRST; // Clear SW reset, resume operation
    IE2 |= UCB0RXIE | UCB0TXIE; // Enable RX/TX interrupt
    UCB0I2CIE |= UCSTPIE + UCSTTIE; // Enable STT and STP interrupt
    i2c_busy_flag = 0; // Clear flag
    //UCB0I2CIE |= UCSTTIE; // Enable STT
    }
  • D Galli,

    Is there anything in the macros that get executed before the 500ms delay that could influence pins on the connector or on another board? Without the full schematic and code, I can't tell for sure what all those do.

    Going down a slightly different path, it looks like you have some sort of motor on each board. Can you describe what the motor is used for and how it is connected? Motors can be very noisy on the power rails, which could cause spikes that could damage the device.

    I don't know for sure that the motors could be causing issues, I'm just tossing out some ideas about potential problem areas that I see.

    Mike
  • Yes Mike,

    We do have to eliminate all possibilities as far as the motor is concerned.

    So the motor is a low power AC motor running at 120Volts at about 50mA or less (very small motor). The power for this motor comes in on a completely separate wire harness that does not come into proximity of the signal lines and the board is designed to have an opto-triac drive from the micro to the AC control. The board has a small area where the AC is contained and both the PCB VCC and GND plane are removed from that section limiting any interaction from the DC side to the AC side. 

    Just an FYI - The motor only runs for a very short time at low duty cycles in this machine maybe a second or two every several minutes. And at no time during these incidents has the motor been running as on the bench as it is removed from the chassis and no AC is applied during these test that find the port damage problem.

    I will be seeing the client this afternoon and will be taking some current measurements while stepping the program on the IDE. Maybe there will be some clues in that data. Hope to continue this after about 4 today.

  • Mike Pridgen said:
    Without the full schematic and code, I can't tell for sure what all those do.

    Then please tell how in particular circuit i2c pull-up resistors can damage i2c pins of supposedly not yet powered-on slave msp430.

  • Ilmars,

    Ilmars said:
    Then please tell how in particular circuit i2c pull-up resistors can damage i2c pins of supposedly not yet powered-on slave msp430.

    I2C pullup resistors on an unpowered MSP430 will cause a high voltage on the the pin, which violates the maximum allowed voltage on a pin spec.  We (Texas Instruments) do not guarantee any behavior on the device when operating out side of spec.  While in principal, I agree that the current limit from the pullup resistor and the internal protection diode to the VCC rail will likely prevent any catastrophic failure, I cannot guarantee that is the case.  This is also why I asked if any other connections were made to the 430 from other boards.  Even if voltage is applied to another pin and damage the device, that damage is internal and could be adjacent to the I2C pins in silicon, which is then the failure that is observed.

    D Galli,

    Were you able to get any additional information after your visit yesterday?

    Mike

  • Mike Pridgen said:
    I2C pullup resistors on an unpowered MSP430 will cause a high voltage on the the pin, which violates the maximum allowed voltage on a pin spec.

    I am afraid that if max diode current is not exceeded, then protection diode will do it's job - protect pin from overvoltage. Mike, please confirm that this statement is correct.

  • Mike,

    Here are some numbers from yesterday.

    A set of 4 boards in series was used (that's all we have right now) and power was applied to the same type power supply in the system (only this is set up in a test bench) 

    Time to power output of bench supply 200uS (startup time of the power supply) Ramp to 12 Volts was 50uS

    Time to ramp LDO 350uS

    Delta in LDO ramp across all 4 Power supplies on PCB <30uS, all these supplies did come up concurrently with deltas of less than 0.3 volts difference across the 30 uS 

    Inrush current of all boards was greater than the measurement range of my current probe of 700 mA for about 40uS. Note that there are many uF of bypass in the chain. Just on the 12 volt input (before the LDO's) there is over 200 uF and this could easily be this in-rush. The current swiftly settles to just under 170 mA for all 4 boards. And the LED - "a'm alive" sequence is seen at 570 mS after POR. all seems to be exactly as expected in this area.

    I say no indication of port contention during anytime in the first several seconds. Resolution on the probe / scope settings was down to 2 mA so if a port were n contention a spike of greater than 5 divisions on the scope would have been seen.

    Not much to tell here but I wanted to get this information out. Seems that the port setup does not seem to be the culprit. 

**Attention** This is a public forum