0
\$\begingroup\$

I am using an ATTiny88 MCU as master over an Si4012 slave. The MCU is running code produced by Arduino IDE. Connecting a logic analyzer to the SCL and SDA lines produce an output as below - second scren grab. This logic analyzer may not be the best: if I try connecting its CLK input to SCL line then the I2C interface stops working ( and I do not know where else to get a clock signal for the analyzer from). Thus the analyzer is running its own internal clock while sampling @ 16 MHz. However, I can't see why there is this 1.953 kHz SCL reading coming from. Tried with both 100 and 400 kHz SCL rates - the analyzer shows the same 1.953 kHz clock rate... How come ? Any quick other way to establish the real I2C frequency without a scope ?

#define F_TWI             400000L
//#define F_TWI             100000L

....

  Wire.begin(); // Initiate the Wire library
  Wire.setClock(F_TWI);

enter image description here

As per Olin's comment - new image. Forgot to mention the two pullups are 3k3 and the rail is 3v3. Also I should note that the clocks of I2C and logic analyzer go out of sync quite fast as it can be seen in the first screen grab of the first image. Oh, and the MCU is running on its internal oscillator at 1 MHz.

enter image description here

\$\endgroup\$
  • \$\begingroup\$ The analyzer tracer are far too compressed to be able to see anything useful. Try capturing just a single message, like start, address byte, stop. With that expanded to the 640 pixels we get here, we have a hope of seeing what is actually happening. Also, it would be good to see scope traces. That way we can see the rise and fall times, and whether the signals look noisy or not. \$\endgroup\$ – Olin Lathrop Nov 6 '17 at 11:37
  • 1
    \$\begingroup\$ Regarding one of your queries (I can't answer your main question with the information given): "This logic analyzer may not be the best: if I try connecting its CLK input to SCL line then the I2C interface stops working" I'm guessing that your analyser is one of the Saleae clones, since you are using Saleae software, but I'm not aware of a genuine Saleae with a dedicated CLK input pin. On the clones, the CLK pin is usually an output, so it's not surprising that connecting that CLK pin to your I2C SCL signal causes problems. Don't do that. \$\endgroup\$ – SamGibson Nov 6 '17 at 12:13
  • \$\begingroup\$ @OlinLathrop new enlarged image, unfortunately I don't have a scope. \$\endgroup\$ – kellogs Nov 6 '17 at 12:43
  • \$\begingroup\$ @SamGibson oh, I had no idea... yes it is a Saelae knock off. \$\endgroup\$ – kellogs Nov 6 '17 at 12:44
0
\$\begingroup\$

Your new expanded trace appears to show a normal IIC transaction. There is a start condition, then the address byte of E0h, then NACK, then a stop condition. The address byte value of E0h means the 7-bit address was 70h (=112), and the transaction was a write. The NACK means that either there was no slave at 70h, or it didn't respond for some reason.

Assuming we can take the time indicators in the trace at face value, the clock rate is a little below 2 kHz.

Basically, this shows normal IIC behavior, and your interpretation of the trace seems correct. I'm not sure what else there is to say.

\$\endgroup\$
  • \$\begingroup\$ that NACK is misleading I guess, as the slave is operating just as it has been instructed to, subsequent write instructions all have ACKs. Anyway, my question was why the 1.952 kHz clock ? Shouldn't it be 100 / 400 kHz as I have programmed it to be ? \$\endgroup\$ – kellogs Nov 6 '17 at 13:03
  • 2
    \$\begingroup\$ @kell: That's a programming question. If you got 2 kHz but intended 100 kHz, then you have a bug. You messed up something in the code. I'm not sure what you expect us to say beyond that. \$\endgroup\$ – Olin Lathrop Nov 6 '17 at 13:07
  • \$\begingroup\$ Whoever downvoted this, what exactly do you think is wrong? \$\endgroup\$ – Olin Lathrop Nov 12 '17 at 13:49
0
\$\begingroup\$

The problem was due to the 1 MHz frequency I am running the MCU at. It is simply to low in order to sustain a 100 kHz I2C bus. Applying the forumla from the datasheet produces a negative TWBR, which translates in some high byte value, hence the low and apparently not changing I2C ferequency observed.

The fastest I can do is 64 kHz with TWBR = 0, but this is against the datasheet which specifies a value of at least 10 for master mode; I am not sure if I could get away with it or what the negative consequences of going lower than 10 were. If anyone knows, please leave a comment.

As a sidenote, the misleading NACK Olin has noticed was caused by the slave not being fully awake when I have started talking to it.

\$\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.