UNO I2C clock stops unexpectedly.

I'm confused as to why the I2C clock from the UNO stops after some repetitions when the SCL line is connected to a device.
I'm using the following program:

#include <Wire.h>
//I2C-OSC Freqency setter
//I2C: A4 (SDA), A5 (SCL)
const byte I2C_Write =(0x2E >>1);// I2C write address =0x17
const byte x=0xFF;

void setup()
{
Wire.begin(); // join i2c bus (address optional for master)
}
void loop ()
{
Wire.beginTransmission(I2C_Write);
//Wire.write(x);
Wire.endTransmission();
delay(5);
}

The interfaced device is an I2C-OSC module. I have attached a schematic for the module. It is fed with 5V and ground, SCL and SDA from the Arduino.
I don't understand why the loop of the programs produces a valid clock (SCL) for some few seconds and then stops (leaves the line high) altogether until the UNO is manually reset, after which the same thing happens.

Note that there is a normal repeated clock when the SCL wire to the module is disconnected and the UNO is reset.

PS: If I lengthen the delay, the SCL clock lasts longer, but still stops in a few seconds.

I2C-OSC_Schematic.pdf (25.7 KB)

I2C devices have to reply with an ACK bit as part of the tranfer. Is the device responding?

from the lib

x = uint8_t TwoWire::endTransmission(void)

  • Output 0 .. success
  • 1 .. length to long for buffer
  • 2 .. address send, NACK received
  • 3 .. data send, NACK received
  • 4 .. other twi error (lost bus arbitration, bus error, ..)

I was under the impression that the SCL line idles high once data transmission is complete.

I can no longer reproduce the problem. It may well have been a loose wire on the breadboard. I never seem to have any luck with hardware.
But the module is still not working. I just need to look at it to describe the problem.

@Crossroads: "I2C devices have to reply with an ACK bit as part of the tranfer. Is the device responding?"
Yours was a puzzling comment. The program is in a loop of writes. Why would an ACK stop everything? OR are you saysing that at some point, the WIRE library hung because it missed an ACK?

@ robtillaart "x = uint8_t TwoWire::endTransmission(void)". That was REAL good to know. I will use it. Seems I should keep the library code handy.

@ Jack Christensen: "I was under the impression that the SCL line idles high once data transmission is complete." It does, but there is a write loop that continually sends an address.

Again...can't seem to reproduce it for now.
Thank you all.

louarnold:
But the module is still not working. I just need to look at it to describe the problem.

For the life of me, I can't download the PDF in the original post. I get error 503 from the web site when I click it. Could you post a link to this device?

How often will communications be required? I heard a story once about an I2C device that was overloaded by too-frequent bus communication and it affected its internal operation as a result.

Is 0x2E the write address? Then 0x2F would typically be the read address. The read/write bit is the least significant bit with zero indicating write and one for read. Shifting the address by one bit ( >>1) seems unusual, but without knowing anything about the device or seeing the datasheet, I can't be certain.

[quote author=Jack Christensen link=topic=143287.msg1077504#msg1077504 date=1358529562]
For the life of me, I can't download the PDF in the original post. I get error 503 from the web site when I click it. Could you post a link to this device?
[/quote] The URL for product info is at: I2C 1KHz to 68MHz Programmable Oscillator. There is a link to the user manual, but the schematic has to be requested via the sales email address. I also get the 503 error when I try to download it. Perhaps its been deemed to be proprietary.

How often will communications be required? I heard a story once about an I2C device that was overloaded by too-frequent bus communication and it affected its internal operation as a result.

This is no longer the problem. Ignore the code in my first post.

Here is the current problem:
The module is sent a count that sets an oscillator frequency. That frequency is determined by the high 14 bits of an unsigned word. The two MSB enable or disable the two clock outputs. The SDA and SCL lines have 4.7K pull-ups, and the waveforms look good on the scope.
The current program sends one oscillator value at setup time. Nothing is sent in the "loop()". The problem now seems that higher values don't get to the module. I have to power down the module and the UNO and then power up the UNO and the module in that order. Once the module powers up, the output goes to the set frequency.

Is 0x2E the write address? Then 0x2F would typically be the read address. The read/write bit is the least significant bit with zero indicating write and one for read. Shifting the address by one bit ( >>1) seems unusual, but without knowing anything about the device or seeing the datasheet, I can't be certain.

This is the technique needed by the Wire library.

louarnold:
Here is the current problem:
The module is sent a count that sets an oscillator frequency. That frequency is determined by the high 14 bits of an unsigned word. The two MSB enable or disable the two clock outputs. The SDA and SCL lines have 4.7K pull-ups, and the waveforms look good on the scope.
The current program sends one oscillator value at setup time. Nothing is sent in the "loop()". The problem now seems that higher values don't get to the module. I have to power down the module and the UNO and then power up the UNO and the module in that order. Once the module powers up, the output goes to the set frequency.

Post your current code, let's see what we're dealing with.

Is 0x2E the write address? Then 0x2F would typically be the read address. The read/write bit is the least significant bit with zero indicating write and one for read. Shifting the address by one bit ( >>1) seems unusual, but without knowing anything about the device or seeing the datasheet, I can't be certain.

This is the technique needed by the Wire library.

I am not so sure about that. Why do you say that? Reference, link, etc.?

I had a look at the LTC6904 datasheet and also the user manual.

I'm with you on the address, 0x17 is the correct value to give the Wire library. But there is an address pin (ADR, pin 4) on the chip that can modify this. With a low value on pin 4, 0x17 would be the address, with a high value on pin4, 0x16 would be the address. The user manual indicates this is set via a solder jumper on the board.

The module is sent a count that sets an oscillator frequency. That frequency is determined by the high 14 bits of an unsigned word. The two MSB enable or disable the two clock outputs.

I think you meant the two least significant bits?

Serial Port Register Description
OCT[3:0] – Frequency Divider Setting. (See Frequency
Setting Information Section)
DAC[9:0] – Master Oscillator Frequency Setting. (See
Frequency Setting Information Section)
CNF[1:0] – Output Configuration. This controls outputs
CLK and CLK according to Table 2.