You might want to execute a I2C bus reset too. If you protocol still has a bug in it you might be fighting for the bus.

But the I2C is pulled high and outputs are open-collector (ie devices can only affect the bus by temporarily grounding the pin, the pullup resistors hold in quiestent high).

Reading is the tricky thing as most people miss the last bit clock switch.

I'd recommend writing a simple routine to address a byte, write it, read it. Use in-line programming until you've proven that you control the device and THEN make you code structure nice.

The NOP is a waste of time. If you want to put off tuning the time intervals for later you can put in big delays in the bit routines. The interface is Asyncronous so you can run it as slow as you want. Running is slow will remove one variable as you deduce your problem.

I assume your micro IS able to pull the I2C bus low. If not, then go kick a hardware engineer and he'll fix it or else go kick an assembly technician for a soldering mistake.

If you can pull the I2C bus low, you don't have to kick yourself. Its just that you haven't properly addressed the device so that it knows its time to control the bus. Reading I2C is the hardest part of the interface as it has all the commonly overlooked special signal requirements.

By all means, at the beginning of your write to the I2C device, begin with an I2C RESET sequence (maybe I'm thinking of 1-wire interface). Make sure that you put the I2C device in a known state before you start an exchange. This is more important while you are checking out your interface code as there are higher chances of protocol mistakes.

I think the way to RESET the I2C is to do a sequence of false read bits but I'll let someone else look it up. :)

aka J