I2C slave. How to reset the SSP peripheral?

kender · Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley

Colleagues,

I have an I2C bus and occasional large quantities of EMI in my instrument. I2C bus connects two PICs: master and slave. Fortunately, I know when the EMI periods start and stop, and I don’t have to communicate over I2C only between the periods of EMI. However, EMI still gets into the I2C bus and I suspect that it sets the SSP peripheral on the slave into some bad state. I want to reset the SSP peripheral on the slave at the end of every EMI period, now can I do it?

Thanks,
Nick
_________________
Read the label, before opening a can of worms.

Ttelmah · Guest

I'd suggest probably disabling the peripheral, when you are not using it. (turn off the SSPEN bit), and then when you wake it back up, clear the SSPOV, and WCOL bits (the latter would only get set if you tried to write, SSPOV, is the 'likely' one to get set). So (for a 18 chip), something like:

rnielsen · Joined: 23 Sep 2003 Posts: 852 Location: Utah

I2C is not recommended in environments that have high EMI. If you have no other choice you might try bit-banging the bus and not use the built-in commands.

Normal I2C buses are short which keeps them from being affected by noisy environments. I've needed to have a master talk to a slave that was 32 feet away. The normal built-in I2C commands would choke everytime so, I went to bit-banging the bus and it took care of the lock-ups. This took a bit of experimenting with delays and when/how to read the ports to check for ACK/NOACK and to check if the slave was holding the bus 'busy'.

I believe the Philips I2C specification notes the standard way to reset the bus in case it gets 'fouled' up.

Ronald
Why are there no Father-in-Law jokes?

kender · Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley

Ttelmah · Guest

As a comment, I have had cause to use I2C, in a 'noisy' environment. My solution (which has proved very good indeed), was to completely use my own I2C code, implementing 'timeouts', inside all the driver waits, and resetting the peripheral if there were problems, combined with using a P82B96 driver, with 12v drive, twisted pair connections for the IC lines, and opto-coupling. This has been in use for a couple of years, over distances of typically about 10m, and has proven completely reliable.
I'd add, that even without this extra hardware driver, two things made all the difference. The first was the driver re-write. I have a 'tick' interrupt running at 100Hz, and when an I2C transaction starts, a counter is set. If the whole transaction has not completed when the counter reaches zero, the timeout recovery is triggered. The second thing was that if opto-coupling was not present, it was _vital_ to add your own protection on the I2C lines. Something like a transorb where the lines enter the board. If EMI spikes are reasonably large, letting these flow through the internal protection diodes, can lead to code hangups. Without the protection, or opto-coupling, I was seeing a couple of watchdog restarts an hour on test (my code will watchdog if certain operational parameters are not met). With the protection added, this dropped to zero.
For me, I2C, was a 'forced' decision on this unit, but with care, it can be made to work well.

Best Wishes