This is a software issue, you are spending too much time servicing interrupts & your I2C routine is not able to handle it (so that's two things which are not right). I have been through several similar situations.
First: You need to do as little as possible in the interrupts, only read & store the data, don't do any processing that you could do outside the ISR, maths can take a LOT of CPU cycles and the CPU cannot do anything else while in that interrupt.
Second: Investigate DMA to automate things, so your interrupts become almost a background automated process.
Third: If I2C is important, put THAT in an interrupt too, but make sure you work out the priorities!
Fourth: Work out why your I2C routine is failing, I2C itself can stand up to very intermittent timings, pauses & waits etc. so your routine may need modifying to allow this.
Fifth: See if you can "chain" interrupts, you may find you can service the ADC reads more efficiently, or put the ADC in a different mode where it does more work for you before interrupting (EG wait for all readings to be available, then read all in one hit, rather than 8 separate interrupts for 8 separate ADC channel reads).
Sixth: Use an oscilloscope or logic analyser, and spare IO pins on the board, to trace how much time you're spending in each bit of code, to see if you can speed it up. (Set pin high when you enter a function/ISR, set it low again on exit).
Seventh: Decide if you really need to read the ADC so much, will going slower make things worse? It's counter-intuitive but sometimes running slower actually gives nicer results, doing the work of averaging the signal for you and cutting down on spikes/transients which could cause problems or require extra processing to remove. We improved a motor control PID routine by simply running it 1/4 the speed, freeing up a load of CPU time in the process.
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.
Best Answer
One general solution to unsticking an I2C bus is to just clock the SCL line for 18 or more cycles. This will clock the rest of the current byte out of the slave, let it see a NACK and then clock out one more byte. However, if the slave is very confused, this may not work. Also, most hardware I2C modules cannot do this so you would need to take control of the I2C lines as GPIOs and clock it manually.
Externally driving a reset line to the slave is the best solution. Also, some slaves can be configured to timeout after a relatively long time (e.g. 250 ms).