2
\$\begingroup\$

In our prototype , we have a I2C based EEPROM . During ESD Test(High potential spark is injected into system for a very short moment), the drivers hangs in the I2C code.

Basically there are while loops in which which we are checking is the busy , or transmit flag is set or not, Acknowledge received or not using the respective registers. So , if any of the parameters is not matched , then the code will hang in that loop itself.

This driver works fine in normal conditions.

But during spark injection, it hangs in one of the loops.

And even after the ESD test it remains in the same condition, , it does not recover until we restart the device.

What could go wrong with the controller(MSP430F6438 I2c bus) or the slave(I2c based EEPROM), which causes the code to hang in one of the loops which checks for busy bus, transmitt flag, acknowledge recieved flag?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Are you talking about ESD or EMC testing? ESD testing typically means applying static discharge impulses to various parts of the system, not applying a continuous disturbance. \$\endgroup\$
    – The Photon
    Dec 7 '14 at 6:08
  • \$\begingroup\$ Its ESD testing,, Am soory I gave the description of EMC testing in the question. Any suggestions why it could hang? or the failure of I2C. \$\endgroup\$ Dec 7 '14 at 9:24
2
\$\begingroup\$

While really we can't know what causes your hang-up, there is one likely scenario where you should probably look first.

An ESD pulse is likely to cause an unintended on transition on a digital signals. In an I2C system, if ESD causes a pulse to appear on SDA when the bus is idle, this will be interpreted as a start condition. Depending on how the uC and peripheral I2C controllers are implemented, they could wait indefinitely for the started transaction to complete before they are ready to execute a new transaction (for example, one generated by your code).

Of course an extra pulse on SCL or SDA when an I2C transaction is in progress (maybe detected by only one of the two chips involved) could also cause the two chips to lose track of the state of the transaction and cause problems.

So if you are looking for where your hardware might be improved to avoid this fault, make sure your SDA and SCL lines are routed over unbroken ground planes, avoid excess routing distance, and possibly reduce the pull-up resistor values. Also make sure the uC and peripheral have adequate bypass capacitors.

If you are looking for software work-arounds for this fault, if you can detect the hung condition, you could try resetting the uC's I2C block, or sending SCL pulses (8 or 10 or 16?) with SDA released high to clear the I2C state machine in the peripheral. This might require resetting the uC i/o's to be GPIO's and bit-banging if the uC I2C block is also stuck.

\$\endgroup\$
2
\$\begingroup\$

It sounds like your test conditions are causing the I2C driver code, or the I2C module itself, to enter a state from which they can't recover.

Try putting a timeout on the loops to detect a failure; if a failure occurs then reset both I2C hardware and drivers.

The simplest timeout to implement would be to count the number of times you've tested the various flags and when that count expires, exit with an error code.

A more complicated (i.e. useful) approach would be to monitor a hardware timer that's running in the background. When a loop starts, record the current value of the timer plus the timeout that you want; check the timer at the start of each loop and if it exceeds your pre-calculated value then exit with an error code.

\$\endgroup\$
0
1
\$\begingroup\$

What could go wrong with the controller(MSP430F6438 I2c bus) or the slave(I2c based EEPROM), which causes the code to hang in one of the loops which checks for busy bus, transimit flag, acknowledge received flag?

It's hard to tell which causes your system hang. But you can do something to figure out where you code hang. If possible, you can print some debug message to the screen or to your PC by USART or other interface. You can add some "probe" in your code, when enter a function or enter a loop, you print some message to your PC, then you can know where you code hang.

However it's a good habit to add timeout to a loop may "dead".

\$\endgroup\$
1
\$\begingroup\$

Sort out the flaky code. If the code hangs due to an unforeseen circumstance then alter the code so that the unforeseen circumstance is catered for. As a last resort try a hardware watchdog timer - although this will only work (no code change) if there are some external lines that can be decoded that indicate the problem. You might also consider some EMI protection/filtering on internal wiring and maybe even take a look at the ground plane around the micro and EEPROM.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.